[lively-kernel] Samurai coding

[Daniel Ingalls]

Folks -

Over the weekend i did some Samurai coding.  I haven't been able to do much of this recently, but it is very instructive.

The bad news: I found myself constantly thwarted my minor annoyances.  The good news:  it is clear to me that if we only fixed about a dozen things, Lively could be a true Samurai environment.  For that reason I have taken care to document my experiences...

S1:  It is a real problem to have <save> in the search list (cmd-shift-F) behave differently from in the SCB (System Code Browser).  Even if the message tells you that changes are only local, it simply doesn't work to have cooperating tools with different conventions.

S2:  We must be able to browse old versions of code that we have changed.  Yes, one can use the wiki revert mechanism, but it is way too complex and time-consuming, and usually forces you to revert other things that you don't want to change.  This is easy to do (see Squeak browse versions) and it will pay off the minute we put it in place.  The Samurai knows where he is going and our job is to clear all the obstructions out of his way.

S3:  I'm convinced there is something wrong with the add/remove method logic in the SCB when you use "sorted" mode.  And why wouldn't we use "sorted" all the time?  This should be fixed and sorted should be the default.

S4  The management of keyboard focus and selections is infuriating.  This *has* to be made right.  We can't ask a Samurai to keep making his selections over again just because of changing from one window to another.  And we can't have cmd-D saving a bookmark instead of evaluating a selection just because keyboard focus isn't treated right.

S5:  Pan(two-finger) scrolling still does not work right.  The rule is very simple: pan scrolling should affect only the innermost scrollable context in which the gesture starts.  And it needs to respond immediately.  It either works right or it is a distraction.  We have enough distractions already.

S6:  Text frames *must* have adequate margins.  We can't ask a Samurai to pick single pixels when trying to select a line of text.

S7:  The green save message in the SCB does not appear when the method text is scrolled up.  If we're going to show it, we should show it, eg, in the middle of the frame as in the Object Editor.

S8:  We are paying a huge penalty for not having built a scaling pane structure for windows.  It must be easy to reshape and position windows on the screen.  This should be in the kernel, with a splittable pane in the parts bin.  We need a bit of design here, but nothing that hard.

S9:  For instance it is almost impossible to get a reasonable amount of workspace at the bottom of an inspector.  And also on the inspector, arrays longer than 10 or 20 need to be abbreviated, lest they kill the system.

S10:  It is a huge mistake that we consider syntax errors to be program errors.  The Parser should never break and should not cause any program errors (huge red paragraphs splashed all over the screen).  If there is a syntax error it should be noted either in the text or with a "before..." or "after..." hint.  Why do I call this "huge"?  Two reasons.  First, the whole job of the parser is to find the errors;  why then ask the programmer to find them again without even any help.  The second reason comes next...

Chris's debugger is really great!  I almost started using it all the time.  Except that syntax errors are treated as program errors and thus get slowed down by the need to start up the debugger.  Let's fix the syntax error problem and all start using the debugger.

S11:  We need a console window so we can see console messages without having to use the native console.  This worked nicely in LK1.

S12:  The tools have to be fast.  I'm talking about inspector, object editor, SCB, search panels, and debugger.  It's OK to fetch them from the parts bin once, but they should be cached thereafter.  The delay to respond to a change should not be much more than the time it takes the coder to get ready for it.  Even for this old Samurai, that's about two seconds.

Every one of these obstructions carries a doubled cost.  The first is the time wasted;  the second is the loss in momentum which is much more costly.

I would have (and probably should have) put these all into TRAC, but I think it's important that they be presented as parts of a *gestalt*.  If each of these problems is addressed (and most could probably be addressed in a focussed day of work), we will all be working on an entirely new level.  It will actually make us better.  Even part way through this list, we will be finishing the job faster.  

Maybe someone could turn this into a Samurai page where we can coordinate this work, or put it into TRAC in a way that the gestalt gets preserved -- maybe by adding a new category of priority called Samurai.  I don't want to mess up the current organization, which I think is good.  But I do want to establish a distinct new initiative which is to take our coding power to the next level.

Let's get busy...