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

Ken G. Brown kbrown at mac.com
Thu Feb 22 20:41:54 UTC 2018


See answers within:

> On Feb 21, 2018, at 18:36, tim Rowledge <tim at rowledge.org> wrote:
> 
> 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?

Right now not using very much, just updating and trying a few things out.

> If you don't use Squeak, why not?

Still my favourite, not working on any particular project now.

> If you used Squeak in the past and don't now, what pulled you away?

Some years ago (too many) now at work I started to use Squeak as the basis of a scriptable test framework for end to end cycle testing, injecting known signals into a gas well flow measurement instrument that would report to a server via cell or satellite. Idea was to be able to monitor various pertinent data points in the whole system beginning to end making sure that the integrity of the information remained correct throughout. 
One part of the test suite, was connected to and monitored a single debug serial port on the instrument that was used to turn on and off software test points within the instrument that were enabled and disabled via commands into the port. Also, known measurement data was injected for certain tests. Outgoing streams of data that were enabled and coming from the instrument, were annotated as to which stream or test point they belonged to, and the data was subsequently separated and written to appropriate Squeak windows per stream or combination of streams as needed. 

The project got cancelled before full realization due to company financial constraints and layoffs. A certain amount of resistance to Smalltalk and Squeak was experienced since the shop was Windows only.

> What does Squeak lack that you think might make you use it for 'regular' development?

At the time of the test framework development, it was too easy to overwhelm the serial communications and lose data, perhaps I was doing something wrong. Work remained to be done to ensure reliability of the incoming data stream. 

> What things are too hard or annoying to do?

When a newcomer to Squeak, I learned about entering self halt at various places while learning and following code execution. I found that very intimidating, being afraid of modifying critical Squeak code and not being able to find or undo the modifications later. I’m sure many newcomers feel this way. Some easy way to remove or disable all such debug points from one place might be good.

I would like to see progress made with Craig Latta’s modularity work.

One main thing that I feel could use significant improvement now is SqueakMap. For some reason developers don’t seem to find SqueakMap compelling enough to register their software even though SqueakMap has the potential and I feel could/should be the primary go-to place for Squeak software and documentation. We might be able to make registration on SqueakMap easier to understand and accomplish, and more automatic.

Another item, I would like to see Edgar’s FunSqueak live long and prosper. I think keeping a lot of the old unique projects alive and loadable in latest Squeaks is a good thing, also it is good to see that eToys remains active in Squeak.  SqueakMap would be ideal help for everything loadable and unloadable. 

Another: initial look and feel, e.g. last time I looked, Cuis is much nicer looking at the start.

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

I intend to use Squeak on Raspberry Pi when it arrives, where the heck is that order anyway? 
Would like to find time for a few other projects as well e.g. home accounting that I haven’t gotten to yet, geodesic design, Grafcet…

Thanks a lot for everyone’s  continuing work on Squeak. 

Ken G. Brown

> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> C for sinking, java for drinking, Smalltalk for thinking
> 
> 
> 


More information about the Squeak-dev mailing list