<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 26, 2015 at 9:39 PM, Chris Muller <span dir="ltr"><<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">It's not much "harder" to get to in terms of number of gestures. You<br>
can select "browse class" and, voila, there are your ClassVars, ready<br>
for printing or inspection.<br>
<br>
IMO, we should consider and encourage the idea that interacting with<br>
code in the browsers is as much a part of the IDE as the menus and<br>
buttons.<br>
<br>
<soapbox><br>
This seems like a good opportunity to express my views about what<br>
Squeak is, or at least can be. It seems like there are two prevailing<br>
ideas in the community; one that Squeak should be like an "app" where<br>
the goal is to insulate the user from ever seeing code or the<br>
debugger, and therefore we need a widget (button or menu) for every<br>
action the user might ever want to do.<br>
<br>
The other prevailing idea is that Squeak is devevlopers-tool (like<br>
Eclipse, etc.) and should regard its users as full-on developers.<br>
<br>
It seems like every software out there wants to cater to one of those<br>
two groups, but not anyone who is looking for something else. Squeak<br>
has the chance to be that something else that empowers regular people<br>
who are not programmers, but very intelligent and wanting to use their<br>
computer for useful purposes -- if only they had an empowering<br>
software "application" other than, at one end, some kind of Office<br>
package (usable but not capable) and, at the other, Emacs and a<br>
C-compiler (capable but inaccessible to them).<br>
<br>
As another example, hiding the debugger to put up a generic error<br>
message in an alert box totally subverts the strengths and even the<br>
original vision of the Dynabook. It's supposed to be a personal<br>
computing system, the Debugger is the most useful and empowering<br>
browser in the system. The Squeak environment should never swallow<br>
its own bugs.<br>
<br>
Another example is breakpoints vs. "self halt". We have all<br>
this.... crazy stuff to support them; swapping out CompiledMethods,<br>
restoring them under certain circumstances, and even creating a new<br>
soft-dependency from Compiler to Tools! All this, just so the user<br>
can select "breakpoint" from a menu instead typing "self halt" in a<br>
method? IMO, "sparing" the user from interacting directly with the<br>
code is not helping them in the long run..<br>
</soapbox><br></blockquote><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>Look at this issue where you yourself missed a error because a class variable was nilled:</div><div><br></div><div><a href="http://forum.world.st/Etoys-specialist-needed-td4739904.html">http://forum.world.st/Etoys-specialist-needed-td4739904.html</a><br></div><div><br></div><div><br></div><div><soapbox></div><div>Sometimes it is ok to dig into the underpinnings of a system, and get the whole developing environment.</div><div>Sometimes you can't be bothered with a debugger, you just want to get the stuff you are working on done. </div><div>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.</div><div><br></div><div>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. </div><div><br></div><div></soapbox></div><div><br></div><div>Karl</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div><br>
<br>
On Wed, Aug 26, 2015 at 6:10 AM, karl ramberg <<a href="mailto:karlramberg@gmail.com" target="_blank">karlramberg@gmail.com</a>> wrote:<br>
> Hi,<br>
> There is no menu item to inspect or explore the class of the inspected<br>
> instance. Many constants hide in class variables and are harder to get to<br>
> when there are no menu short cuts.<br>
><br>
> Karl<br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div></div>