On Wed, Aug 26, 2015 at 9:39 PM, Chris Muller <asqueaker at gmail.com> wrote:

> It's not much "harder" to get to in terms of number of gestures.  You
> can select "browse class" and, voila, there are your ClassVars, ready
> for printing or inspection.
>
> IMO, we should consider and encourage the idea that interacting with
> code in the browsers is as much a part of the IDE as the menus and
> buttons.
>
> <soapbox>
> This seems like a good opportunity to express my views about what
> Squeak is, or at least can be.  It seems like there are two prevailing
> ideas in the community; one that Squeak should be like an "app" where
> the goal is to insulate the user from ever seeing code or the
> debugger, and therefore we need a widget (button or menu) for every
> action the user might ever want to do.
>
> The other prevailing idea is that Squeak is devevlopers-tool (like
> Eclipse, etc.) and should regard its users as full-on developers.
>
> It seems like every software out there wants to cater to one of those
> two groups, but not anyone who is looking for something else.  Squeak
> has the chance to be that something else that empowers regular people
> who are not programmers, but very intelligent and wanting to use their
> computer for useful purposes -- if only they had an empowering
> software "application" other than, at one end, some kind of Office
> package (usable but not capable) and, at the other, Emacs and a
> C-compiler (capable but inaccessible to them).
>
> As another example, hiding the debugger to put up a generic error
> message in an alert box totally subverts the strengths and even the
> original vision of the Dynabook.  It's supposed to be a personal
> computing system, the Debugger is the most useful and empowering
> browser in the system.  The Squeak environment should never swallow
> its own bugs.
>
> Another example is breakpoints vs. "self halt".    We have all
> this.... crazy stuff to support them; swapping out CompiledMethods,
> restoring them under certain circumstances, and even creating a new
> soft-dependency from Compiler to Tools!  All this, just so the user
> can select "breakpoint" from a menu instead typing "self halt" in a
> method?  IMO, "sparing" the user from interacting directly with the
> code is not helping them in the long run..
> </soapbox>
>

It's not so much isolating the user from the system as making a practical
system that group somewhat similar issues together. When I inspect a
running instance I know I can browse it's class and get to the class
variables.

One of the biggest failures of Smalltalk is hidden state. When code behaves
strangely and you are looking for clues, easy access is a prime quality.

Look at this issue where you yourself missed a error because a class
variable was nilled:

http://forum.world.st/Etoys-specialist-needed-td4739904.html


<soapbox>
Sometimes it is ok to dig into the underpinnings of a system, and get the
whole developing environment.
Sometimes you can't be bothered with a debugger, you just want to get the
stuff you are working on done.
To get somewhere you have to stand on the shoulders of giants and trust
that they made the right choices. You can't always go down the rabbit hole.

When I write this mail I don't want to debug TCP or know why the cursor
change was lagging while I moused over a hyperlink.

</soapbox>

Karl


>
> On Wed, Aug 26, 2015 at 6:10 AM, karl ramberg <karlramberg at gmail.com>
> wrote:
> > Hi,
> > There is no menu item to inspect or explore the class of the inspected
> > instance. Many constants hide in class variables and are harder to get to
> > when there are no menu short cuts.
> >
> > Karl
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150826/ccbe2052/attachment.htm