[squeak-dev] Survey: what do you do with Squeak, what do you *want* to do?

Chris Muller asqueaker at gmail.com
Sat May 5 22:10:33 UTC 2018


Thanks for doing this survey, I finally gathered my thoughts and time
to participate.

> At the latest board meeting we got to discussing the relative quietness of the squeak list(s) recently. We were wondering what you folks out there are doing with Squeak, what you'd like to be able to use it for, the things that you think would be important to improve it for wider use and so on.
>
> Please, whether you're a frequent user or an occasional look-at-the-list type, take a moment to let us know your opinions.
>
> What do you use Squeak for?

I use Squeak to augment my thinking.   Not just as a calculator
(although I could not do my taxes without it, literally), but as a way
to force myself to contextualize something by modelling it as a
domain.  It's been an incredibly illuminating tool for understanding
things at a deeper level than I otherwise could.

> If you don't use Squeak, why not?
> If you used Squeak in the past and don't now, what pulled you away?
>
> What does Squeak lack that you think might make you use it for 'regular' development?

What does Squeak lack?  Squeak lacks fulfillment of the vision of
Smalltalk to be a personal computing tool for non-developer users.  It
still can, the domain of "sending messages to objects" is something I
believe users curious enough to use a spreadsheet, but not interested
in developing full-blown applications, would grasp as easily as 1-2-3:

   1) An object appears on the screen.
   2) Some widget on the object provides one or a (filtered) list of
message selectors the user is allowed to send, shown by their **actual
implementation names** in the class.
   3) The invocation of the message causes its return value to appear
as another object on the screen.  Return to step 1.

Nuturing this process into a beautiful and usable UI could provide a
level of leveraged access to domain models that is very powerful, yet
easy to understand.  Displaying the actual message selector names is
key, not just for serving as a useful "language" to converse with the
domain developers, but also as a stepping stone to the next layer
deeper into the system where, like, if they pressed "Help" on a
(high-level) message, the system response could be to show its actual
implementation in a code-tiles view such as Etoys / Scratch /
Elements.  Seeing the assemblage of other message names they've used
before causes them to grok the system at the level they need to
understand it properly.
This is why it is crucial for as much of the class library to remain
with utmost clarity AND brevity of code as it can, without wordy
comments to bloat up the widget.

> What things are too hard or annoying to do?

Convincing my colleagues of the importance of the above.

> What would you like to be able to use Squeak for?

To publish rich, interactive domain models to the web at the push of a
button, which users can use their client of choice to access them.
I'm currently working on a GraphQL parser and server to try to
accomplsh this.

 - Chris


More information about the Squeak-dev mailing list