Last weekend I've played a bit with LabView:
http://www.frank-buss.de/LabViewSilabsTest/
It's really fun to "program" in it: You just drag'n'drop some GUI elements
on the instrument view, add some more symbols on the diagram view, draw
some connections and it just runs. Unfortunately LabView is very expensive
(I have a test version for non-commercial use) and sometimes the GUI is a
bit complicated to use with all these different windows. Would be cool to
implement something similar in Lisp. Are there already some Lisp frameworks
which I can use for dataflow, GUI, network, serial port, USB etc., platform
independant?
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
On 14 fév, 09:02, Frank Buss <····@frank-buss.de> wrote:
> Last weekend I've played a bit with LabView:
>
> 49http://www.frank-buss.de/LabViewSilabsTest/
>
> It's really fun to "program" in it: You just drag'n'drop some GUI elements
> on the instrument view, add some more symbols on the diagram view, draw
> some connections and it just runs. Unfortunately LabView is very expensive
> (I have a test version for non-commercial use) and sometimes the GUI is a
> bit complicated to use with all these different windows. Would be cool to
> implement something similar in Lisp. Are there already some Lisp frameworks
> which I can use for dataflow, GUI, network, serial port, USB etc., platform
> independant?
>
> --
> Frank Buss, ······@frank-buss.de51http://www.frank-buss.de,52http://www.it4-systems.de
Not in Lisp but somewhat excellent however, there is openDX
http://www.opendx.org/. There are different ways to play with it in
Lisp : see http://www.femlisp.org/ and http://www.bondy.ird.fr/~delerue/DXScm/index.html
In the dataflow mind, in Lisp (with FFI to a part of GTK), there is
openmusic http://recherche.ircam.fr/equipes/repmus/OpenMusic/
On 14 fév, 09:02, Frank Buss <····@frank-buss.de> wrote:
> Last weekend I've played a bit with LabView:
>
> 49http://www.frank-buss.de/LabViewSilabsTest/
>
> It's really fun to "program" in it: You just drag'n'drop some GUI elements
> on the instrument view, add some more symbols on the diagram view, draw
> some connections and it just runs. Unfortunately LabView is very expensive
> (I have a test version for non-commercial use) and sometimes the GUI is a
> bit complicated to use with all these different windows. Would be cool to
> implement something similar in Lisp. Are there already some Lisp frameworks
> which I can use for dataflow, GUI, network, serial port, USB etc., platform
> independant?
>
> --
> Frank Buss, ······@frank-buss.de51http://www.frank-buss.de,52http://www.it4-systems.de
Not in Lisp but somewhat excellent however, there is openDX
http://www.opendx.org/. There are different ways to play with it in
Lisp : see http://www.femlisp.org/ and http://www.bondy.ird.fr/~delerue/DXScm/index.html
In the dataflow mind, in Lisp (with FFI to a part of GTK), there is
openmusic http://recherche.ircam.fr/equipes/repmus/OpenMusic/
Patrice Lespagnol wrote:
> Not in Lisp but somewhat excellent however, there is openDX
> http://www.opendx.org/. There are different ways to play with it in
> Lisp : see http://www.femlisp.org/ and http://www.bondy.ird.fr/~delerue/DXScm/index.html
This looks a bit like http://www.theprodukkt.com/theprodukkt#10
But I'm not sure how good it is for general programming tasks.
> In the dataflow mind, in Lisp (with FFI to a part of GTK), there is
> openmusic http://recherche.ircam.fr/equipes/repmus/OpenMusic/
Thanks. The name is a bit misleading, but it looks better, more general,
not just for composing music and creating sounds. I'll take a closer look
at it when I have some time.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Paul Tarvydas
Subject: Re: dataflow implementation in Lisp?
Date:
Message-ID: <fp1ls8$pnm$1@aioe.org>
Frank Buss wrote:
More references - not exactly what you asked for - but they might generate
ideas:
www.visualframeworksinc.com (shameless plug - see the two published papers)
http://st-www.cs.uiuc.edu/users/brant/HotDraw/ (oop (smalltalk, java) figure
drawing package that I wish was also ported to CL)
http://www.jpaulmorrison.com/fbp/ (Paul Morrison's Flow Based Programming)
http://www.alice.org/ (visual scripting of 3D graphics)
http://www.lispworks.com/documentation/lw50/CAPRM/html/capiref-135.htm and
http://www.lispworks.com/documentation/lw50/CAPUG-W/html/capiuser-w-118.htm
http://subtextual.org/OOPSLA07.pdf (Jonathan Edward's Subtext)
pt
Paul Tarvydas wrote:
> More references - not exactly what you asked for - but they might generate
> ideas:
>
> www.visualframeworksinc.com (shameless plug - see the two published papers)
You wrote that you can compile it to embedded systems like ones with 8051
CPUs. How fast is it compared to e.g. hand written assembler code or C
code, devlopment time and runtime performance?
> http://st-www.cs.uiuc.edu/users/brant/HotDraw/ (oop (smalltalk, java) figure
> drawing package that I wish was also ported to CL)
I have heard of this framework, looks interesting. If it is possible to
port it to Java, it should be a piece of cake porting it to Lisp.
> http://www.jpaulmorrison.com/fbp/ (Paul Morrison's Flow Based Programming)
Thanks, I'll read the book on this page. Looks like there are some basic
ideas discussed, which are still important, despite the age of the book.
> http://subtextual.org/OOPSLA07.pdf (Jonathan Edward's Subtext)
This looks a bit abstract and difficult to use.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Paul Tarvydas
Subject: Re: dataflow implementation in Lisp?
Date:
Message-ID: <fp2bbo$6h5$1@aioe.org>
Frank Buss wrote:
> Paul Tarvydas wrote:
>
>> More references - not exactly what you asked for - but they might
>> generate ideas:
>>
>> www.visualframeworksinc.com (shameless plug - see the two published
>> papers)
>
> You wrote that you can compile it to embedded systems like ones with 8051
> CPUs. How fast is it compared to e.g. hand written assembler code or C
> code, devlopment time and runtime performance?
We OEM this stuff. Each case is different.
The 8051 case was in the mid-90's. I vaguely remember someone benchmarking
their hand-written pseudo-assembler to our stuff for similar apps (POS
terminals) in the same company. Our stuff was 1.3 times slower than
pseudo-asm. VF was (maybe still is) infinitely faster than C++ on an 8051,
since there wasn't (maybe still isn't) a C++ for 8-bit 8051's with only 32K
of RAM. At the time, the C compiler(s) produced code that could not be
used - the app didn't fit on the hardware (only 128K-256K of ROM and 32K
RAM) when written in C. Our OEM design for this customer employed a VM
written in assembler to crush the code size down (and the result was
apparently only 1.3x slower than their hand-written pseudo-assembler,
iirc - the 8051 is a strange beast).
The last OEM version we built was for ARM processors. The visual tool was
completely built in CL (and Norvig-like prolog). Comparative statistics
not known - the customer first wrote the embedded app in C and could not
get it to work reliably. They rewrote it in our tool in half the time (but
by then understood the domain better) and were demoing when a financial
after-shock from [dot-bomb cross-product 911] hit them.
In general, I believe that development time takes "longer" (more thought is
expended up front), integration time drops drastically (since integration
is mostly done before coding commences) and reliability (due to up-front
architecture) goes up. Schedulability goes up (since you are dealing with
100's of highly encapsulated, independent components).
(If this discussion is deemed OT, then we can continue with private emails,
if you wish).
pt
Frank Buss wrote:
> Last weekend I've played a bit with LabView:
>
> http://www.frank-buss.de/LabViewSilabsTest/
>
> It's really fun to "program" in it: You just drag'n'drop some GUI elements
> on the instrument view, add some more symbols on the diagram view, draw
> some connections and it just runs. Unfortunately LabView is very expensive
> (I have a test version for non-commercial use) and sometimes the GUI is a
> bit complicated to use with all these different windows. Would be cool to
> implement something similar in Lisp. Are there already some Lisp frameworks
> which I can use for dataflow, GUI, network, serial port, USB etc., platform
> independant?
It *really* sounds like you are looking for a Cells driven GUI. Kenny,
you might have found your guy :-)
You might want to look at
- Cells for the data flow
- Celtk/Cello [1] for the GUI. (cells-gtk [2]is only Windows/Linux since
GTK for OSX is not yet there)
- IOlib [3] for networking
Peter
[1] http://common-lisp.net/cgi-bin/viewcvs.cgi/?root=cells#dirlist
[2] http://common-lisp.net/project/cells-gtk/
[3] http://www.cliki.net/IOlib
Peter Hildebrandt wrote:
> It *really* sounds like you are looking for a Cells driven GUI. Kenny,
> you might have found your guy :-)
>
> You might want to look at
>
> - Cells for the data flow
Thanks, I now it a bit. Sometimes it looks a bit ad-hoc programmed and
without much documentation it is difficult to understand and use it.
Is it possible to use Cells with a GUI driven concept? It would be nice to
construct Cells classes with the GUI instead of writing some sourcecode for
it. Then only a very abstract base is sufficient and the rest could be
"programmed" with the GUI.
But writing the classes in classic Lisp code is ok, too, if it is possible
to instantiate the Cells by names and connecting it at runtime.
LabView has some interesting concepts for the connection points: There are
typed connection points, e.g. for the serial port component, there is a
connection point for the port number, which accepts integers, only and
there are some more sophisticated components, like arrays, where the output
type is dependant on the input type. I think features like this needs some
major additional work on the Cells framework.
> - Celtk/Cello [1] for the GUI. (cells-gtk [2]is only Windows/Linux since
> GTK for OSX is not yet there)
OSX would be nice. There is a screenshot for GIMP on Mac:
http://www.gtk.org/screenshots.html
so maybe it works for OSX, too? And then cells-gtk works for OSX?
> - IOlib [3] for networking
Looks like this doesn't work for Windows and Mac, but this is not too
difficult, I've started my own library some time ago, but needs some
bug-fixing and more documentation :-)
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss wrote:
> Peter Hildebrandt wrote:
>
>> It *really* sounds like you are looking for a Cells driven GUI. Kenny,
>> you might have found your guy :-)
>>
>> You might want to look at
>>
>> - Cells for the data flow
>
> Thanks, I now it a bit. Sometimes it looks a bit ad-hoc programmed and
> without much documentation it is difficult to understand and use it.
(Redirect to Kenny ;-))
> Is it possible to use Cells with a GUI driven concept? It would be nice to
> construct Cells classes with the GUI instead of writing some sourcecode for
> it. Then only a very abstract base is sufficient and the rest could be
> "programmed" with the GUI.
This is somewhat what I am doing in my project. Primitives (which are
essentially cells classes (models) can be created through the gui (based
on cells-gtk), and the same for connections. Updates of the model are
then automagically represented in the GUI.
I use cairo for the drawing and programmed a drawing area widget in
which each primitive is a cells model instance, which can be dragged
around, connected to other instances by arcs, and the list of properties
can be inspected/modified. Shape and Color of the primitive represent
its internal state.
I plan to merge this into a future release of cells-gtk, but right now
it is very much WIP. Kenny has been working through the hell of porting
cells-gtk to Cells3, and right now I am fixing up some problems which
came up in the process. Once this is done, I will merge in the cairo
drawing area (and hopefully soon thereafter the opengl drawing area).
> LabView has some interesting concepts for the connection points: There are
> typed connection points, e.g. for the serial port component, there is a
> connection point for the port number, which accepts integers, only and
> there are some more sophisticated components, like arrays, where the output
> type is dependant on the input type. I think features like this needs some
> major additional work on the Cells framework.
Depends on how you do it. I am facing similar issues, and my approach
is (somewhat different from lab view) using a tree view widget for all
object inspecting/editing. My cells tree view uses custom models to map
cells models into tree view fields. Basically there is one mapper model
for each internal model, and the mapper model knows how to use the
internal model to convert its data into something printable in a tree
view (doing some consing and prin1-to-strings) and how to deal with
input from the tree view (using read-from-string and some
splitting/coercing).
This can all be done nicely with cells, especially since we have clos
and multiple dispatch.
If you are interested in any of these things, you can have a look at the
current code, but don't expect it to work completely. The
functionality is mainly there, but it needs quite a bit of cleanup,
before I'd call it a library.
>> - Celtk/Cello [1] for the GUI. (cells-gtk [2]is only Windows/Linux since
>> GTK for OSX is not yet there)
>
> OSX would be nice. There is a screenshot for GIMP on Mac:
>
> http://www.gtk.org/screenshots.html
>
> so maybe it works for OSX, too? And then cells-gtk works for OSX?
To be honest, I haven't checked in a while. Plus, I don't have a Mac,
so I can't really try things out.
>> - IOlib [3] for networking
>
> Looks like this doesn't work for Windows and Mac, but this is not too
> difficult, I've started my own library some time ago, but needs some
> bug-fixing and more documentation :-)
Very good. Looking forward to it.
Peter
Peter Hildebrandt wrote:
> Frank Buss wrote:
>
>> Peter Hildebrandt wrote:
>>
>>> It *really* sounds like you are looking for a Cells driven GUI.
>>> Kenny, you might have found your guy :-)
>>>
>>> You might want to look at
>>>
>>> - Cells for the data flow
>>
>>
>> Thanks, I now it a bit. Sometimes it looks a bit ad-hoc programmed and
>> without much documentation it is difficult to understand and use it.
>
>
> (Redirect to Kenny ;-))
Kenny has redirected Cells to Arc:
http://smuglispweeny.blogspot.com/2008/02/arc-cells-baby-steps_14.html
No, I am not going to document that, either.
kt
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Ken Tilton wrote:
> Kenny has redirected Cells to Arc:
>
> http://smuglispweeny.blogspot.com/2008/02/arc-cells-baby-steps_14.html
So you like Arc? Looks like you have to implement your own object system,
first, but CLOS is too complicated anyway and some strange syntax is always
better than long-winded Lisp names.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss wrote:
> Ken Tilton wrote:
>
>
>>Kenny has redirected Cells to Arc:
>>
>> http://smuglispweeny.blogspot.com/2008/02/arc-cells-baby-steps_14.html
>
>
> So you like Arc?
Not so far. Ask me again after I port Cells to it, gotta give it a
couple of days to be fair, should be a month but haven't the time.
> Looks like you have to implement your own object system,
> first, but CLOS is too complicated anyway
Yep. I am done with OO, too rigid. All RDF all the time for me, even in RAM.
> and some strange syntax is always
> better than long-winded Lisp names.
I use a text editor, the long names are not so bad. You really should
try one, punch cards are manly and everything but...
:)
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Edi Weitz
Subject: Re: dataflow implementation in Lisp?
Date:
Message-ID: <uk5l7q2te.fsf@agharta.de>
On Thu, 14 Feb 2008 10:02:26 +0100, Frank Buss <··@frank-buss.de> wrote:
> Are there already some Lisp frameworks which I can use for dataflow,
> GUI, network, serial port, USB etc., platform independant?
Not exactly what you want, but maybe something you'll want to look at
is David McClain's SigLab:
http://weitz.de/eclm2006/
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> Not exactly what you want, but maybe something you'll want to look at
> is David McClain's SigLab:
>
> http://weitz.de/eclm2006/
I found only a zip package with source code. Do you have some more detailed
description or some screenshots?
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Edi Weitz
Subject: Re: dataflow implementation in Lisp?
Date:
Message-ID: <uejbfi8fm.fsf@agharta.de>
On Thu, 14 Feb 2008 21:15:50 +0100, Frank Buss <··@frank-buss.de> wrote:
> I found only a zip package with source code.
That's more than you'll get for most other programs.
> Do you have some more detailed description or some screenshots?
No, except that everybody who saw the talk was amazed. You should
have been there... :)
http://www.lispworks.com/success-stories/raytheon-siglab.html
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On 2008-02-14 04:02:26 -0500, Frank Buss <··@frank-buss.de> said:
> Last weekend I've played a bit with LabView:
>
> http://www.frank-buss.de/LabViewSilabsTest/
>
> It's really fun to "program" in it: You just drag'n'drop some GUI elements
> on the instrument view, add some more symbols on the diagram view, draw
> some connections and it just runs.
"Those who cannot remember the past are condemned to repeat it."
-George Santayana
<http://en.wikipedia.org/wiki/Prograph>
This whole discussion has come up before, and even then it was about
why visual programming didn't work in the past:
<http://groups.google.com/group/comp.lang.functional/browse_frm/thread/75b4f878fa16b23f/1447506658a97944?hl=en&lnk=st&q=#1447506658a97944>
From: Paul Tarvydas
Subject: Re: dataflow implementation in Lisp?
Date:
Message-ID: <fp20uc$21b$1@aioe.org>
Raffael Cavallaro wrote:
> On 2008-02-14 04:02:26 -0500, Frank Buss <··@frank-buss.de> said:
>
>> Last weekend I've played a bit with LabView:
>>
>> http://www.frank-buss.de/LabViewSilabsTest/
>>
>> It's really fun to "program" in it: You just drag'n'drop some GUI
>> elements on the instrument view, add some more symbols on the diagram
>> view, draw some connections and it just runs.
>
> "Those who cannot remember the past are condemned to repeat it."
> -George Santayana
>
> <http://en.wikipedia.org/wiki/Prograph>
>
> This whole discussion has come up before, and even then it was about
> why visual programming didn't work in the past:
>
> ...
"Epicycles"
- Ptolemy, et al.
http://en.wikipedia.org/wiki/Epicycle
Visual programming didn't work in the past because of researchers' &
developers' insistence on using the epicycle commonly known in software
engineering as "call-return".
Get rid of call-return (i.e. use a reactive, asynchronous, event-driven
paradigm) and visual programming works just fine.
pt
On 2008-02-14 13:25:47 -0500, Paul Tarvydas
<········@visualframeworksinc.com> said:
> Get rid of call-return (i.e. use a reactive, asynchronous, event-driven
> paradigm) and visual programming works just fine.
Read my usenet posting mentioned in my previous post. The reason visual
programming doesn't work is not because of the use of call-return, but
because of the absence of syntactic abstraction. Text/sexp based
langauges can use syntactic abstraction to abstract away a great deal
of low level dataflow detail.
Visual dataflow languages use dataflow diagrams. Once they use anything
else they are no longer visual dataflow languages. iow, If they use
syntactic abstraction so that, for example, icons represent the
equivalent of lisp macros, they cease to be visual dataflow languages
and become symbolic languages. At this point we're just discussing how
pretty we want our symbols to look on screen.
What characterizes a visual dataflow language is that the icons/glyphs
on screen actually *look like* the flow of data. They are signs not
symbols. Symbolic programming and the syntactic abstraction of macros
breaks this correspondence between what the glyphs on screen look like
and the flow of data in the program.
The limitation of visual dataflow languages is the limitation of any
single paradigm language - not everything we might wish to express can
be shoehorned into one paradigm.
From: Paul Tarvydas
Subject: Re: dataflow implementation in Lisp?
Date:
Message-ID: <fp3322$bc9$1@aioe.org>
Raffael Cavallaro wrote:
First, to clarify...
Your first message:
> This whole discussion has come up before, and even then it was about
> why visual programming didn't work in the past:
refers to "visual programming", which I take to mean any form of visual
programming. Your second reply refers to "visual dataflow languages",
which is a small subset of visual programming, IMO. Which did you mean?
> Read my usenet posting mentioned in my previous post. The reason visual
> programming doesn't work is not because of the use of call-return, but
OK. Done.
Please read the few paragraphs in Section 4.1 of the first paper
http://www.visualframeworksinc.com/CCECE06-0379.pdf
to see what I mean about call-return.
This is/was certainly one of Prograph's failings.
Along with that, Prograph (and its ilk, incl. UML) attempt to *re-encode*
all existing programming knowledge as diagrams - and they fail miserably in
the attempt(s).
Instead, visual programming should be used to *augment* the state of the art
of programming.
One such augmentation would be to describe the thing that I
call "architecture", i.e. how does one compose a complex system using
software components, and how does one make such a system understandable,
and how does one communicate this "architecture" to non-programmer domain
experts? I'm quite convinced that Common Lisp is the epitomic repository
of all possible programming paradigms currently employed, but, I'm also
convinced that it (and programming in general) is growing away from -
instead of converging on - answering the preceding question.
In the following, I don't know if I'm addressing the rest of your points, or
only my misunderstanding of them.
> because of the absence of syntactic abstraction. Text/sexp based
> langauges can use syntactic abstraction to abstract away a great deal
> of low level dataflow detail.
Why can't a "line" or a "rectangle" be a syntactic abstraction? One can
certainly create a grammar of graphic units and scan the grammar and parse
it.
If you create a grammar of symbols for boring, already-existing concepts,
e.g. "+", "-", "*", "if", etc. then you haven't achieved much that is new.
If you create a grammar for things that we can't represent easily in text,
then you might be on to something worthwhile.
Take, for example, the concept of "listeners" in Smalltalk. A powerful
concept, but no existing syntax. (I suspect that Kenny's Cells is a
variant of this concept, and he probably has a better syntax for this than
smalltalk). Try to follow where a message goes, or who a listener listens
to.
Wouldn't it be nice to have a concrete diagram to follow? A diagram whose
grammar was not ad-hoc, where diagrammatic entities can be type-checked and
are semantically complete (i.e. can be compiled by a compiler). That's the
type of thing that visual programming is (should be).
> Visual dataflow languages use dataflow diagrams. Once they use anything
> else they are no longer visual dataflow languages. iow, If they use
> syntactic abstraction so that, for example, icons represent the
> equivalent of lisp macros, they cease to be visual dataflow languages
> and become symbolic languages. At this point we're just discussing how
> pretty we want our symbols to look on screen.
Here, you've switched to talking about the subset, visual dataflow
languages. I will continue to discuss the broader concept.
When a normal human looks at a diagram, the implicit understanding is that
the entities are independent, encapsulated and asynchronous. Most visual
languages have failed because they treated the entities as synchronous,
i.e. simply try to re-encode already existing programming paradigms, almost
all of which are based on call-return (which is an insidious form of
synchronization).
In a "real" visual language, then, icons do not devolve to lisp macros, they
devolve to lisp processes. If you look at a visual program containing
(hierarchically, to manage the complexity) 1,000 icons, you expect to see
1,000 processes under the hood. Not macros. Every lisp function gets its
own process assigned to it. (My papers show how to achieve this effect
without using heavy-weight processes).
> What characterizes a visual dataflow language is that the icons/glyphs
> on screen actually *look like* the flow of data. They are signs not
> symbols. Symbolic programming and the syntactic abstraction of macros
> breaks this correspondence between what the glyphs on screen look like
> and the flow of data in the program.
... because call-return is being used under the hood.
If each lisp function lived in its own process, the syntactic abstraction
would not break down.
>
> The limitation of visual dataflow languages is the limitation of any
> single paradigm language - not everything we might wish to express can
> be shoehorned into one paradigm.
Yeah, now, here we disagree! I'm firmly of the opinion that, after 50 years
of glomming stuff onto the discipline of "software engineering" - i.e. the
Precambrian Explosion - it is nigh time for an asteroid to hit the planet
and to cull the phyla. I hang around this newsgroup because I think that
Common Lisp embodies everything that can (and should be allowed to :-)
exist in a textual language. Visual programming is the next
(non-exclusive) step - we have to augment our methods of "programming" and
raise them to levels of Engineering and Architecting (complete with laws
about certification, afixing seals and ascribing legal accountability).
We've known about "processes" for decades, but have been avoiding them and
allowing them to be inefficiently implemented. If we want to break through
to diagrammatic programming, we need to make everything (effectively) a
process and to find ways to make this efficient. And, we need to find
structured ways to organize such diagrams. (Frankly, we need to solve
exactly the same issues if we want to crack the distributed and multi-core
problems in full).
pt
On 2008-02-14 23:08:02 -0500, Paul Tarvydas
<········@visualframeworksinc.com> said:
> Please read the few paragraphs in Section 4.1 of the first paper
>
> http://www.visualframeworksinc.com/CCECE06-0379.pdf
>
> to see what I mean about call-return.
>
> This is/was certainly one of Prograph's failings.
But not the most important one.
>
> Along with that, Prograph (and its ilk, incl. UML) attempt to *re-encode*
> all existing programming knowledge as diagrams - and they fail miserably in
> the attempt(s).
This was the main one. I think we are in violent agreement[sic] here.;^)
>
> Instead, visual programming should be used to *augment* the state of the art
> of programming.
again, agreed, (as with Frank - see my latest response to him).
Ideally one would be able to use visual representations where those
were perspicuous and purely symbolic representations where those work
best, and to freely mix both. Unfortunately, most visual programming
systems make the mistake of ignoring the fact that the historical
movement away from literal diagrammatic representation to arbitrary
symbolic representation happened for a reason - symbolic
representations, being free of the need to literally depict something,
are generally more concise and therefore, more powerful.
Raffael Cavallaro wrote:
> "Those who cannot remember the past are condemned to repeat it."
> -George Santayana
>
> <http://en.wikipedia.org/wiki/Prograph>
>
> This whole discussion has come up before, and even then it was about
> why visual programming didn't work in the past:
>
> <http://groups.google.com/group/comp.lang.functional/browse_frm/thread/75b4f878fa16b23f/1447506658a97944?hl=en&lnk=st&q=#1447506658a97944>
Ok, looks like Prograph failed, but LabView is very popular. What do you
think are key features needed for such a dataflow programming "language" or
why do you think a linear text form for writing program is better?
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
On 2008-02-14 15:46:13 -0500, Frank Buss <··@frank-buss.de> said:
> What do you
> think are key features needed for such a dataflow programming "language" or
> why do you think a linear text form for writing program is better?
Because it frees us from the constraint that the glyphs we see on
screen must *look like* the flow of data in the program (or any other
aspect of the program for that matter). It is the difference between
signs and symbols. An up-arrow points up. It is a sign. The english
word "up" does not. It is a symbol. Symbols allow greater abstraction.
Raffael Cavallaro wrote:
> Because it frees us from the constraint that the glyphs we see on
> screen must *look like* the flow of data in the program (or any other
> aspect of the program for that matter). It is the difference between
> signs and symbols. An up-arrow points up. It is a sign. The english
> word "up" does not. It is a symbol. Symbols allow greater abstraction.
This sounds like an interesting problem. You are right, many graphical
computer languages are limited: You define your symbols and draw a diagram
with it. And a great subset of the graphical languages are even more
limited to the dataflow pattern. A bit more level-mixing may help: E.g. a
symbol, which implementation expands it into a diagram, with the help of
other symbols (constants, part-diagrams). This would break a bit the
schematic-only aspect of dataflow languages and provides some kind of
macros.
An example is the while-loop in LabView: It is a box, where you can place
symbols into. There is a special point, to which you connect a boolean
output value. The symbols inside are executed, as long as the boolean value
is true.
I think the while-loop is some kind of hardcoded into LabView. Some more
general, abstract concepts, which allow to create special symbols like the
while-loop, would be nice.
A good test-case would be the symbol set of LabView, e.g. the normal
symbols and all special symbols, like the while loop, the sequence etc. The
general concept should be so abstract, that you can even build the concept
of a normal symbol itself, with inputs and outputs and the concept of wires
to connect it. It would be implemented in the usual recursive fashion: The
symbols which are executed, are used to construct the symbols which are
executed, like many Lisp systems are used to compile their own Lisp
systems.
I think using icons for programming is not a limitation, but it needs some
researching to find good ideas how to use it. With a general concept you
could even define a graphical language, with which you can write Chinese
Kanji, which is some kind of ordered (at least Simplified Chinese, see
http://en.wikipedia.org/wiki/List_of_Kangxi_radicals ) and which itself is
a good example of how you can use signs to express abstract concepts.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
I agree with you that the ideal tool would be a multi-paradigm language
that allowed graphical dataflow programming where desired, but also
allowed symbolic programming, especially the ability to create new
symbolic primitives a la lisp.
However, keep in mind that for a language to be truly graphical, it's
glyphs and their arrangement must look like what they represent. It is
in the nature of symbols that they do not look like what they
represent. The more purely symbolic capablilites you add to a graphical
language, the less graphical it becomes.