[lively-kernel] Samurai coding

[Fabian Bornhofen]

Had a go at S4 and created a git branch for it:
https://github.com/rksm/LivelyKernel/tree/samurai_fixes

Best,
Fabian

On Wed, Mar 14, 2012 at 5:45 AM, Jens Lincke
<jens.lincke at hpi.uni-potsdam.de> wrote:
> Hi, Dan -
>
> thank you, that you took the time to write these issues down. I added them
> to track and created a new milestone for them
> http://lively-kernel.org/trac/query?status=assigned&status=new&status=accepted&status=reopened&group=status&milestone=M4+-+Samurai+Coding
>
> The question is now: How to proceed? Some of the issues are clear how to
> address them, but some are trickier and will take longer to solve.
>
> Are there any volunteers to tackle the issues?
>
> Best,
> Jens
>
> Am 12.03.2012 um 18:19 schrieb Dan 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...
> _______________________________________________
> lively-kernel mailing list
> lively-kernel at hpi.uni-potsdam.de
> http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
>
>
>
> _______________________________________________
> lively-kernel mailing list
> lively-kernel at hpi.uni-potsdam.de
> http://lists.hpi.uni-potsdam.de/listinfo/lively-kernel
>