Adult e-toys - warning: long and a little rambling

Adult e-toys - warning: long and a little rambling;
The long and somewhat meandering reply it inspired.
>
Hi James,

I'm a coder who found squeak a while back (turn of the
century). The first thing I did was look around for a
way to express myself. I started with etoys, and found
it too limited for making fully useful programs.


Playing with morphic I fell in love with the idea that
I could assemble already existing widgets to get
applications without writing a line of code. And of
course got frustrated when I reached for widgets I
needed that didn't really exist.

======

Adult etoys.

I did have coding skills and I eventually put on my
programming hat to make the widgets I wanted. (Curvier
and Mixed curves. Popup snapshots of morphs,
retargetable sliders and buttons amoung others.)
Squeak is immenently repairable.  All the tools (with
one exception) help in that direction.

My first perception was that 1/3 of the way thru a
coding project I found myself at "done". I had done
what I had set out to do (at least in a useable if
somewhat crude form). My current perception (now
squeak centric) is that other ways of doing things
would take me three times as long.

======

On the other hand squeak itself is a cluttered
collection of a lot of contributers code.  At some
point the contributor focuses on another project,
direction or interest.  Much of the code in squeak is
half finished.  A self-funded coder loses no money by
abandoning a project midstream and not cleaning up.
And self-funded coders who will spend their time
cleaning up other peoples messes are few and far
between.

Squeak and tweak reference Lewis Carroll a lot.
Particularly the Mad Tea party. The code of squeak has
a lot of that feeling  to it. I imagine it is the same
for tweak.

=====

Etoys
I also am interesting in seeing etoys that children
can share with their fathers, (and mothers).
The OPLC project and scratch project have attracted
the major talent directed towards developing etoys.

So any major development within squeak-dev would be
more tepid and also diverge from the main stream of
etoy development (OPLC) or the cutting edge (MIT's
Scratch).  So the best stratgy for us would be to
follow the lead of either or both of those two groups.
 OPLC is doing ongoing development and so what they
are doing is unstable and constantly changing.

Scratch has been released and has solved some really
good problems of representing loops and making
different shapes for differnent parts of program
speech. The work they have done will be released under
an MIT license but not as source until this summer at
the earliest.  

Melding the work of both groups would be the next
interesting thing to do. No way to work on it until
time passes. For users I would suggest getting the
very available OPLC stuff and see how they have
improved things. An look at what MIT has done. One of
their designers also designed what became morphic.

====

Etoys versus Adult Etoys

As a programmer making contributions to morphic I
presently feel like a man without a country.
People on the squeak-dev list are directing much of
their efforts to the web applications of squeak.  They
program by writing smalltalk code in omnibrowsers.
The thought of programing in a limited tile system
does not occur to them even for an instant.

On the OPLC side the main developer keeps reminding
other that "Etoys is not a productivity tool". And
Etoys designers make decisions that please educators
but that keep the Etoys from achieving their full
potential.  

Between the two of us, the first time I saw etoys I
said "O boy, I can do all my programming by connecting
tiles together. How clever. And squeak, being smart,
will do everything in its power to make life easy for
me." I still want to do things that way.

Unfortunately, that is not what Etoys was meant to
accomplish. And the implementation is cumbersome and
gets in the way of really elegant improvements.

======

The talk on this list about removing Etoys is partly
from those who have no current need for it.
(They probably don't have children they want to share
squeak with.) And those who do but who realize that
the implementation is limited both by design and the
clumsy but expedient implementation.

To them the version squeak-dev serves up should be
clean and robust. Worth building upon.

======
To me, squeak needs a child oriented component. People
keep asking well where are you going to get the people
resources to maintain that component.  They forget to
look around and realize those people resources are
growing up all around them. They are just as old (i.e.
as young) as we were twenty, forty or fifty years ago.
 

When people say squeak is all about objects Alan (Kay)
reminds us its all about sending messages to objects.
Coding for squeak is teaching objects how to hear and
what to do with messages.  In the end Coding squeak is
like telling stories to objects.  Like telling stories
to children.  The etoys component of squeak stregthens
squeak by retaining the fun you need to attract an
audience. And by reminding us that squeak is what it
has always been and growing to be more so.

========
Tweak

Tweak is being created under the same pressures (and
by the same people) that created squeak. The bugs and
the clutter are likely to be repeated and the time it
will take to get them down to a reasonable level is
still measured in years.
My test is that triangles (polygons) in tweak don't
work in a usable fashion. They shrink if you turn
them. NOT acceptable.  

Also the testing of code in the tweak enviorment is
meant (expediently) to insure it works in the tweak
enviorment. No work will be done making it work in the
squeak enviorment unless something makes that
"worthwhile".  This is as it should be.

Developing with two focuses rathar than one would be
daff. And I would not relish having to run twice the
tests if I were developing something as exotic as
tweak.

HTH.

Yours in service, --Jerome Peace


>
>J F fnordlator at gmail.com
>Sun Feb 4 16:43:06 UTC 2007 wrote:
>
>Hello all,
>I feel compelled to add my point of view due to
recent discussions on this
>list; I have kept quiet for a long time as I'm not a
professional programmer
>and haven't contributed code so my point of view
doesn't hold much weight
>but I hope to be expressing a wish that other silent
readers have - if not,
>I'll quietly go away and see what other solutions can
do for me.

>First, some background: I was first introduced to
computers as a child, on
>Apple ][ machines at my father's work, on which I
learned to program in
>basic, making little games. I then progressed to a
ZX81 at home and then a
>spectrum, all of which there was an easy route into
programming. I then
>spent around 15 years without a computer and when I
finally got a PC was
>horrified - I had a computer which (out of the box) I
couldn't use to
>compute!
>I have since dirtied my hands with all sorts of
programming languages and it
>took a long time before I stumbled over squeak.
Squeak has been an amazing
>and enlightening adventure for me but I have never
really used it. The thing
>that has kept me interested even though I don't use
squeak (except to
>explore squeak itself) is Alan Kay's dynabook vision.
This is how I'd like
>to use my computer (or even better, my pda.)

><...>
>There are many RAD ways of building native
applications - wxPython, wxRuby,
>wxPerl... You get the idea. I'm sure wxGNUSmalltalk
would be possible. For
>me, the beauty and the power of squeak is in the
direct manipulation of
>objects.

>I would love to see Tweak in the main image.

> There is a lot of talk about
>cleaning up morphic and the huge effort it would
require. Would it not be a
>better idea to spend that effort getting Tweak
functional in the main image?


>I'm sure there are many ways that the etoys
environment and tile scripting
>could be expanded upon to create more advanced
programming possibilities for
>the non-expert like myself.
><...>

>James
>
>


 
____________________________________________________________________________________
It's here! Your new message!  
Get new email alerts with the free Yahoo! Toolbar.
http://tools.search.yahoo.com/toolbar/features/mail/

On Feb 7, 2007, at 1:20 , Jerome Peace wrote:

> Tweak is being created under the same pressures (and by the same  
> people) that created squeak.

Yes and no. There is an "R" in "VPRI" for a reason. Finishing  
something to product quality is not something they can do. But they  
are putting stuff out under an open license, so anyone interested  
could polish it.

> The bugs and the clutter are likely to be repeated

"Likely"? Sounds like hearsay. From my experience, Tweak code is a  
lot cleaner than Morphic in general. I attribute this to the fact  
that the core was developed by a single person, that it is developed  
using Monticello, which separates the experimental code from the core  
pretty much.

> and the time it will take to get them down to a reasonable level is  
> still measured in years.

Well, then better get started sooner than later, right? ;-)

> My test is that triangles (polygons) in tweak don't work in a  
> usable fashion. They shrink if you turn them. NOT acceptable.

Well if this is your only test ... Remove  
CPolygonPlayer>>onGeometryChanged. Done - but it looks ugly, which is  
why the buggy hack is in there. And nobody fixed it because the  
*real* fix is something else.

I wrote about this before. You need a real transforming canvas  
framework to make this work without hacks. Which we did not have  
before Rome. In the TinLizzie Tweak version this test works fine, and  
looks gorgeous even when rotated thanks to Cairo. But again,  
TinLizzie is only a research prototype, development has moved on  
already.

- Bert -