[Edu-sig] Visual Programming in Python?

[Dethe Elza]

On 4/15/06, kirby urner <kirby.urner at gmail.com> wrote:
> Did you mean this to go to the list?  I just responded to one of
> Andre's that was to me privately.  I don't want to abuse my right to
> declassify too much.

Yeah, I meant to go to the list, still getting used to using GMail for
responding...

> > While we're dreaming, how about a library that let's me make
> > "Incredible Machine"-like Rube Goldberg-esque contraptions and
> > puzzles?
> >
> > On 4/15/06, kirby urner <kirby.urner at gmail.com> wrote:
> > > Given Python is so OO, my first concern would be whether this
> > > flowchart-driven system would push us back to a more loopy/blocky
> > > procedural style.  I'd like to see what this would look like on paper
> > > before I was persuaded it was a worthwhile undertaking -- not that I'm
> > > any kind of gatekeeper or funder in this regard, so pay no attention.
> >
> > I don't see why this would be any less OO than writing code.  You
> > would still be manipulating objects, just laying out their
> > interactions graphically rather than procedurally. Lego Mindstorms
> > does this fairly well, though the graphical environment is limiting
> > enough that folks reverse-engineered it so they could write code
> > procedurally again.
> >
> > --Dethe
> >
>
> I think we *could* imagine a graphical language that was OO, but the
> original description a few posts back didn't seem to accommodate that.
>  It's not trivial.  What happens when you clone 30 objects of the same
> type and each has state or is responsive to events.  I've used Lego
> Mindstorms and although it's graphical, I found it more procedural
> than trully OO.

OK, well I haven't actually used the Mindstorms software (doesn't run
on a Mac), so maybe that was a bad example.  And the description on
this list was more about flowchart-type programming.  I guess I'm
biased by using things like Interface Builder, which does exactly what
you mention above: Clone (well, instantiate) the objects and give you
access to their state, let you drag them around and wire them
together.  Pure Data[1] lets you visually wire together objects, and I
think Processing[2] does as well (could be wrong here, haven't played
with it for awhile).  So it is possible.

[1] http://puredata.info/
[2] http://www.processing.org/

> Of course there's a big difference between design time and run time.
> You can have a visual interface for designing objects more easily than
> one for showing what's happening on execution, other than the running
> of the program itself (like Sims).

Different views for looking at the program vs. looking at the running
of the program.  Gelertner's book "Mirror Worlds" is all about looking
at data in real-time, giving manipulatable graphic representations of
information (which could be information about the program, or current
events, or whatever).  In HyperCard you could view the cards as a
program, or you could look at the scripts which were driving each
button and tweak those.  On OS X there are "widgets" which are
lightweight graphical programs that you can "flip around" and change
their state (mostly preferences) on the back.  Lots of possibilities
here.

> However, even the design time interfaces I've worked with that tout
> their graphicalness require some coding e.g. the Visual Studio type
> environments.  GameMaker is another example of a highly visual design
> time environment, but with viewable source code if you want to see it.

Sure.  It depends how much is acceptable.  There are going to be words
in there somewhere.

> Making the visual <-> source relationship fully "round trip" as the
> original poster suggested, e.g. you could parse the source and create
> a graphical version as a result, seems HIGHLY problematic.  The visual
> environments I know about and use on the job don't really advertise
> that.

Yes, any time you convert from one format to another you tend to add
or remove data (or both).  Either way, it's hard to round-trip. 
Capturing the intent of the data without 100% fidelity is more
achievable.

--Dethe

>
> Kirby
>