Missing menu entry to inspect instance class

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Missing menu entry to inspect instance class

Karl Ramberg
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


Reply | Threaded
Open this post in threaded view
|

Re: Missing menu entry to inspect instance class

Chris Muller-3
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>


On Wed, Aug 26, 2015 at 6:10 AM, karl ramberg <[hidden email]> 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
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Missing menu entry to inspect instance class

Karl Ramberg


On Wed, Aug 26, 2015 at 9:39 PM, Chris Muller <[hidden email]> 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:



<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 <[hidden email]> 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
>
>
>