[Edu-sig] Visual Programming in Python?

[dblank at brynmawr.edu]

>> > 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.

When I asked about such a visual programming project for Python, I was
just thinking out loud, too. So, this discussion is in exactly the right
spirit: what are the pros/cons? how hard would it be? would it help/hurt?

>> 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.

I didn't mention anything about instantiated objects, nor objects at all.
But I would imagine that a successful project could show not only the flow
of a procedure, but also capture the interactions between instantiated
objects. I imagine (maybe) a window for each class, and page of a form for
each method. Other windows might show a timeline of events and current
objects and their interactions.

> 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/

I'll check these out; thanks.

[snip]

>> 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.

I think that this round-trip ability would be required to make it useful
to the growing Python community, and toolbox. That way, people see,
literally, how making a graphical box in one place matches up exactly with
code in a program. DBASE IV, I think it was, did this very well---they had
a graphical editing system for forms, but the form was stored as pure
DBASE code. Foxpro, on the other hand, stored their forms in tables. (I
mention these because Kirby and I both worked in Foxpro for a few years.)
I don't think it would be that hard to do round-trip for Python.

-Doug

> --Dethe
>
>>
>> Kirby
>>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>