On 4/16/06, Andrew Harrington <[EMAIL PROTECTED]> wrote: > Several points on visual programming and flow charts ... > > 1. Visual programming in Python is complicated by the fact that it is > not statically typed. If you want x to be assigned the reference > returned by function f, you cannot be sure of the type, so it is hard to > then be able to have a GUI element to select a method to use with x.
This shouldn't be a huge problem. Visual FoxPro isn't statically typed either (reassign at will, no need to pre-declare type). Dynamic typing is in no way inconsistent with visual GUI programming, round trip or otherwise. > 2. On loops and flow charts. I am clearly behind OOP at all sorts of > levels. My judgment is that OOP texts tend to ignore the fact that > inside methods there are algorithms with good old loops and decisions, > and students have a hard time with them (particularly loops) and they > need to be taught effectively. They are underneath objects, and they > are definitely there and important. A flow-chart-ish approach to > visualizing them might help. I'm not sure. I have tried lots of ways, > but not used flow charts much. You're right, shouldn't ignore that Python methods are procedural code, makes sense to do mini-function coding first, then explore OO coding (except one might visit dot-notation even prior to mini-function coding -- what's worked for me in the 8th grade context). Looping and branching -- can't get around those. Not irrelevant in any way, just because of later OO developments. > Obviously if you are trying to set up a model of a complicated domain, > you are likely to have all sorts of objects, and the interfaces between > the objects are key, and you can use UML, or all sorts of schemes. I > would not use loop modeling tools to model an object-oriented domain at > the top level. Still, if you are going below the level of overall > design to actually programming through a graphical interface, you get to > down to loops and decisions, and a graphical flow through them could > definitely be useful *within* a method. > > Andy I like the idea of diagrammatic representations of problem domains using some kind of boxes and arrows notation, something not too formal and doesn't have to generate code. The imagination glues the diagram to the code -- not a step we should have to automate before continuing with serious-minded CS-type training in a developing world context. I'm very open to more GUI tools coming on-line, but don't see any particular absence as halting progress until we have same. In other words, we already have enough tools to get on with it. I'm not waiting for large new green field development to occur, even if I expect such development to keep occuring anyway. That's good, because bottlenecks are just we don't need any more of at this point. The TIMMS scores tell the story. The situation is critical and needs more than just another long-delay type response. We're not "on hold" waiting for any geniuses to get back to us. Kirby _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
