Pippy and Calculate - Evolution Solution

[Steve Fullerton]

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 <yoshiki at squeakland.org> 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 at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>


-- 
Regards,

Steve
____________________________
Steven C. Fullerton
email: fullerton.steve at gmail.com
cell/voice mail: 619.339.9116
____________________________