On Jan 31, 2008, at 12:27 , Blake wrote:
On Wed, 30 Jan 2008 22:59:54 -0800, Jason Johnson <jason.johnson. 081@gmail.com> wrote:
On Jan 31, 2008 3:58 AM, Blake blake@kingdomrpg.com wrote:
You say this almost like it's a bad thing. It's only bad
when people do (a), and if they do (a) anyway,
I think doing (a) is a bad thing. Anyone can do (a) to a new technology (I know I have, even to Smalltalk once upon a time), and to
Indeed, we agree.
me that means they are not ready to look at it. Moving the wall only changes what they complain about.
Also agreed.
If one is too accommodating one ends up changing Smalltalk to be source file based instead of image based so newbies understand what's going on better.
Squeak isn't source file based, and I doubt any form of presentation could make it so. (Though, I guess maybe if you had the Smalltalk OS, it would probably host something like a source- file based scripting system. Or something.<s>)
I'm talking presentation and navigation. And it's come up as I've wended my way through the Laser Game tutorial. It actually inspired me to try to come up with a modification that would make building tutorials a lot clearer and easier.
That sounds to me like an indication that the Smalltalk browser needs some of the keyboard shortcuts your other environments have. I suppose you achieve some of this by simply dumping a bunch of methods in one text area, but wouldn't it be better to attack the root of the problem?
Well, look, I'm not one to turn down hot keys. I think Bert and I must operate in very different ways, and it wouldn't surprise me to find that there are many different styles of coding. (Or maybe there are just two: Bert's and mine.<s>)
I'm not entirely sure how my name got dragged into this conversation - but I do agree with the rest of your post. Setting up a context that lets you focus on what you're currently working on is helpful. There should be a browser that just shows your "working set", like a couple of packages that make up your application. I used such a browser framework 10 years ago (Application Management Browser IIRC) and it worked nicely, basically each tool had a little checkbox switching the filter to your current app on and off. Very handy.
What I find is that experienced Smalltalkers blend out those distractions mentally, they only "see" the interesting parts. For them it's easy to spot the one interesting sender in a list of a hundred methods, or the stack frame in a debugger 10 places from the top where the error actually happened. But I also see Newbies being overwhelmed by the lack of separation between the system and their code. So improved tools are welcome :)
- Bert -
But the "root of the problem" is visual as well as tactile. It's all very well to have all the source code available all the time, but much of the time, I don't want to have to care. And the remainder of the time, I don't want to see all of it, all the time. I want to see what =I= am working on. More importantly, when I'm teaching, I want students to see =THEIR= code most of the time: I'd like to be able set it up so that the debugger wouldn't go in to the base classes unless asked, because that stuff can be very confusing to a beginner.
One of the most important lessons in programming is that, when you're programming and there's a bug, it's in your own code. Not in the library, not in the compiler, not in the operating system. (If that's not the case, you need a new library/compiler/OS.) I love the encouragement to explore in Smalltalk--I just want to be able to turn it off sometimes.
One nice thing about the debugging stack is that it allows you to flip through the code very quickly. There's a clarity that's not available in the usual object soup.
I recall a study (by IBM, I think) where the amount of code one could see at once was postiively related to productivity. (And yet, I'm the only coder I know with a propensity for conserving vertical space.) I do know that if I'm in method A and it calls method B, and method B is right there? I'm golden. As a corrolary to "the problem is in your code", there's also, "the problem is mostly in the code you just changed". I could see a browser where the methods highlighted their latest changes, like a mini-diff--something also good for pedagogical purposes.
None of this is actually opposed to the Smalltalk philosophy, which encourages the writing of small methods precisely because they're easy to understand. Great. Now let me see more of those little methods, without the real estate needed to make every browser window as effective at browsing the entire universe as it is browsing my code.
By the way, it was my experience with the laser game tutorial that brought a lot of this home (both doing it and watching others). For example, it doesn't leap out at you from a screenshot of a method, whether that method is class- or instance- side. It was always something extra to check--whether that "class" button was a slightly darker shade of green.
===Blake===