View this PageEdit this PageUploads to this PageVersions of this PageHomeRecent ChangesSearchHelp Guide

Squeak Wish List

Summary

Squeak (etoys) should do more. It should gracefully extend into "regular" programming.
This is because there is a need for a graceful on-ramp to real programming, at middle-high school level, and squeak is already close to it.

Without that link, we risk frustrating and turning off many of those currently teaching “real” CS in high school. (“What?! no for loop!??”). Some of this can and will be headed off in the "for programmers" section, which explains some major differences, and how to get around them. It will also explain reasons for some of the limitations. I hope that the folks at squeak central will eliminate some of the more significant limitations, or barring that, that we can make our own "empowered" version or add-on.

Details

Understandings
Motivation

Desiderata

Note1: This is an old list. I've marked moot, or questionable items.

Most Important

If pressed, for each of the following I could come up with many examples for things I think you want squeak to be able to do, which would naturally benefit from the following.
  1. Bounded iteration within a script, such as a repeat loop. Although there are several ways to achieve this at present, they are not convenient.
  2. Handle keyboard events. This may be in the works? The joystick is great for writing games, but if you want a two-person game, you really want keys.
  3. Lgical connectives, compound logical expressions. Yes, you can implement an “OR” via parallel/independent tests, but this obscures meaning. And “AND” cannot be done as gracefully, needing some kind of nesting. “NOT” would be nice, while we’re at it.
  4. Full set of mathematics functions. I noted somebody’s request on the bboard for complex numbers. I’d be happy with trig functions.
  5. Compound arithmetic expressions... parentheses... within tiles, so don't have funny unnatural precedence of smalltalk. [Don’t get me wrong - I was an advocate of RPN way back when HP had their first stack-like calculators (HP-35) and I have not ever really recovered since TI took over. But we need to follow the standard now I’m afraid.]
  6. Timer functions. I don’t mean the timeline-scripting as in flash, but rather ability to reset and check a timer.
  7. Perhaps simpler, a “wait” command, which takes an argument interpreted as time, and causes the script to pause until that amount of time has elapsed.
  8. “Wait until done” tile associated with scripting, which fires another script and pauses execution of calling script until the other script has finished. [Actually, an old note to myself that I’m not sure is accurate suggests that this is the distinction between “object do scriptname” or “object scriptname” commands. If so, this may already be in place. In this case, perhaps better names to clearly indicate the distinction between launching a parallel thread and enforcing sequential execution.] Note2: The answer to my "Actually" and whether this is still needed is hiding in the comments I put together on "control" - elsewhere on these pages.
  9. Simple text I/O. Ideal here would be a way to query user through window, and have their answer loaded into a string variable. An example application I'd be interested in is a dynamic "mad-lib" program that asked for various adjectives, nouns, etc., and spit out a story later. My current approach would be a text box where the user types things, and a script/button which when fired loads the contents into a holder which acts as an array for these accumulated words. But a more direct Q/A facility like microworlds logo would be great
  10. Easier mechanism to find/get some tiles, especially from objects that are to be created dynamically and do not exist at the time I am creating a script. Note3: This limitation is probably only a hassle for advanced users, who presumably have the capability to construct their tiles piecemeal by replacing segments. Note4: We need a "how-to" create piecemeal tiles section. The basic idea is covered in the multi-instance programming project of Scott Wallace on the squeafest2004 project page we have a link to somewhere.

Desirable

These would help in teaching a variety of things about programming, and problem solving in alternative ways.
  1. Allow scripts to act as functions (or “reporters” for the logo crowd).
  2. String operations, concatenation, and substring reference.
  3. Multiple parameters to a script. (I know you can pass a holder, for example, or even a script, which means you can pass anything, but we’re talking convenience).
  4. Streamlined way to create, and use arrays. Presently, the most convenient way I have of doing that is to use a holder, and create new copies of a raw-text prototype to include, and then set holder number-at-cursor which changes the text to hold the number. This works fine, but it might be nice to single out a special array type object, and give it special menu pane functions. While I’m here, I may as well suggest multidimensional ones, or at least 2-dim.
  5. Allow to treat a point (x,y) as a single property of all objects, and support various point-operations (setlocation, midpoint, distance, towards (towards a point)).
  6. New holder commands (available via collections menu) to “delete player at cursor” (currently I see no way to do this other than to send the player at cursor the menu item “delete”) to “insert player at cursor”. Perhaps this is a bug, but insert and insert-at-end, both insert the object at the end of the holder’s list, rendering the former superfluous, and misleading.

Things That Confused Me

LOTS of stuff, I wish I had documented better. Hopefully the current class will document their confusions.
  1. "touchesA" vs Overlaps... strange/confusing. Note5: Ignore this. The command may be gone in current squeak version Overlaps works only for a single specific instance, and it doesn't matter if the object is suspended over the world via mouse-hold. In contrast, touchesA works for all copies of prototype SKETCH, but not for prototype itself, and cannot be holding object with mouse. Doesn't work for non-sketches - things dragged or assembled from supplies.
  2. Menu system confusing... some items found here, others there. never sure where to get various tiles. Note6: I don't seem confused anymore. Perhaps this is just a learning curve. Perhaps I needed a guided tour through the different menus.
  3. Walls should be built around etoys, and prohibit a user from wandering off into the ocean of smalltalk, without specifically overriding some control. At least, there should be a clear demarcation between the etoys environment, and the rest. I don't want to get a tile that describes the namestringinhalo when I accidentally alt-click on the name of an object in its halo. I don't want to browse system classes. There is confusion about what the etoys scripting user "should" be looking into, and what they can look into, and it is possible to wander off into a mess of abstraction while looking for some simple function. The functions available should pertain mostly to the scripting, not the look and feel of the scripting, nor to anything else underneath (or above).

Earlier Confusion

These are things I jotted down earlier, and may reflect confusion I no longer have. If not, then they call for some cleanup or added functionality. If so (i.e., they demonstrate ignorance of some function, or whatnot), then they at least provide useful feedback as to what ways a person can get confused.
  1. Creating a button, and then not having an obvious script to assign it to, or to control its when-firing condition. Ideally, seems one should be able to get a button, assign a script (of some other object) to it in a natural way with tiles, and control whether the scripted object will be normal/paused/ticking, and how it behaves as a function of mouse actions ON THE BUTTON. As it is, I found button creation confusing. Button conditions not all in one place. the "button" choices on the viewer for a button list only a couple. Widest range of choices are available by setting the "when this script should run" parameter (next to the ticking clock). Unfortunately though, these tests will apply to the object, not the button created for the script - i.e., if you write a "car move" script and a button to fire it, with code containing move forward command, and select (mouse exit) or something, the mouse condition pertains to mouse and car, not mouse and button. In order to get desired effect, you need to script the button to send a message to the car. "Whilestilldown" option doesn't seem to work for me. Finally, if you'd like the button to work while mouse is over it, the only way to do this is to script the button, including a test "mouse over" that is available for all morphs. This script would then call another script (say the car) with desired action. [NOTE: previous comments from earlier... not sure if I’d find this same confusion now. If they are inaccurate, then at least they demonstrate the type of confusion a person can have with the interface.]
  2. Creating/deleting objects under program control...it appears that the "copy" one gets, and the "clone", available via the viewer for the object or the halo, respectively, do not create a sibling instance.... which has to be done by hand (not under program control) via the red menu on the halo. moreover, the "tell all", "start all"... scripting options for an object are supposed to get all siblings to do the script, and this indeed works, but it doesn't work for the copys... only for siblings. you see the problem. The objects you create under program control (the copys) cannot be told what to do under program control (can only do this for siblings). [Note... I wrote this a while ago, and am unsure if this is accurate. Experiments may have been confused due to my using touchesA as a sentinel, when I didn’t understand the exact conditions under which touchesA works]

Links to this Page