>> > On 4/15/06, kirby urner <[EMAIL PROTECTED]> 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 > [email protected] > http://mail.python.org/mailman/listinfo/edu-sig > _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
