> > > On 4/15/06, kirby urner <kirby.urner@[...].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@[...].org
>  http://mail.python.org/mailman/listinfo/edu-sig
> 


_______________________________________________
Edu-sig mailing list
Edu-sig@[...].org
http://mail.python.org/mailman/listinfo/edu-sig