Hi All, I am a lurker, but this is an interesting discussion. I am a developer in health applications working with current dev release on a B4. Calculate is impressive; Pippy is impressive. They each serve a purpose which I think fits into an OPLC evolutionist philosophy.
First, there are US toys that are remarkably similar to the OLPC in appearance that comprise a simple 4x4 calculator aimed at the under 5 year old crowd. Large keys that do arithmetic. Guido in his wisdom, incorporated and uses in his tutorial the calculator attributes of python to convey --- not arithmetic --- but the meaning of "interpretive" to a neophyte programmer. I think both activities have a place, and further, should/could be seamlessly integrated so that a child in the Ivory Coast who learns arithmetic using Calculate can discover Pippy and say: "Zoot alors! Je peux faire la même chose dans Pippy !" or something like that. Very constructionist. A intellectual bridge to understanding and learning python prior to being able to comprehend a Fibonacci series (although we want kids to get there as quickly as possible.) As a very simple example of seamlessness, I would change the enter key in the Calculate activity to mimic exactly in size/shape the enter key on the OLPC keyboard -- e.g. square with check box symbol and maybe do the same in Pippy in place of the print key that Yoshiki suggests? I don't think we can escape the fact that the OLPC activity suite will ultimately have to be configurable at the national, school, teacher, and pupil levels. I think there is a reason and purpose for both Calculate and Pippy. Some p.s. thoughts --- Many Applications/Activity developers seem to have a natural inclination to add complexity as the activity evolves --- witness MS Windows. In the OLPC I would suggest that we strive to add simplicity. Will millions of children who grew up using Sugar want to transition to MS Windows when they come of age? I think/hope not. /Steve On 9/5/07, Yoshiki Ohshima <[EMAIL PROTECTED]> wrote: > Hi, Chris, > > > (I'm the Pippy author.) > > (We didn't have much time to discuss with you while I was in > Cambridge two weeks ago...) > > > > Imagine if Pippy has a button called "Print!", which would be > > > located right next to the "Run!" button. And, if "Print!" prints > > > out the results of running the program into the bottom pane, that > > > is pretty much all we need. (For the record, the workspace in > > > Etoys has been there from day one for this purpose.) > > > > This is a useful idea, thanks. At the moment, Pippy doesn't keep any > > variable/program state inbetween "Run!"s (each run is a new Python > > interpreter), so there is no way to do "Ans*2"-style calculations. > > It sounds like you want "Print!" to keep a single interpreter that > > reinterprets the source pane at each click. > > I didn't think about that aspect, but keeping state will be useful. > > > The first version of Pippy used a single Python interpreter that > > executed the program source code in this way, without losing state, > > but that makes it possible to write programs that will not run on a > > fresh interpreter later (as they refer to state that was generated > > as a result of code that no longer exists, or a previous run of the > > code), so I decided against keeping that. > > Yeh, that can happen in a typical workspace programming. But in > Pippy's setting, it would not be much of a problem. "Keep" button can > store the state altogether into a journal entry. > > > Oh! We could have an "example" in Pippy that, when run, gives you a > > Python interactive shell. That should work well; it gives you the > > mode you want (without requiring an extra button), and is useful in > > any case. I'll do that. > > > > I don't think Python's evaluations are useful as a calculator to > > a child, though. You would have to explain this: > > > > >>> 2+2 > > 4 > > >>> 3/4 > > 0 > > > > I would like to add a simple graphics screen to Pippy, but I don't > > intend it to get many more features past that -- I'd like to keep > > it at a simple introduction to input/output programming. > > Yeah, I was aware of the division (/) problem (when I see the last > digit in Calculate falls off to the next line. It would be nice if > you can override the division operator... > > > > We have a real problem of shortage of man-power, so replacing > > > smaller activities that take more time to maintain and document > > > with more powerful ones is probably a good thing. > > > > Just a note that Reinier Heeres is a volunteer, so isn't pulling OLPC > > man-power away from any other projects. > > Well, a volunteer can certainly contribute one of OLPC projects, > right? > > I now see that the timeframe and practical matters will probably > prevent us going to the nice merging point between these different > projects. However, I still contend that similarity is close enough. > So, for example Pippy doesn't have to be confined "this is a Python > thing" mind, but take advantage of similarity. > > -- Yoshiki > _______________________________________________ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > -- Regards, Steve ____________________________ Steven C. Fullerton email: [EMAIL PROTECTED] cell/voice mail: 619.339.9116 ____________________________ _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel