[slime-devel] Re: Inspector features regressed

[Madhu]

* Helmut Eller <m2tzhlvo1z.fsf at common-lisp.net> :
Wrote on Mon, 28 Apr 2008 20:20:40 +0200:

|> The default slime inspector used to support a variable called
|>        SWANK::*SLIME-INSPECT-CONTENTS-LIMIT*
|>
|> which was useful if you had to inspect large objects for certain
|> programs with some characterestics.  This customization has been
|> removed[1] by Helmut's patches of 2008-02-09, replaced with hardcoded
|> behaviour which is a pain in the ass for a few use cases [that I
|> commonly use I can elaborate on these, if someone is interested]
|
| I would be interested.

Working with a large array (say 510 elements) is the most simple example
which springs to mind.  Imagine you want to inspect the last 10 objects,
by going forwards and backwards in the inspector buffer..  If you cannot
customize the variable you are forced to hit MORE for every element >
500.

Again, large datasets pose a problem with SLIME.  Here mechanism to deal
with it was in place.

|> As in the case of slime history behaviour, the concern here is that
|> existing useful functionality has again been removed in the [false name]
|> of simplifying things, and replaced with something significantly worse.
|
| Not every feature is it worth have, but simplicity is not optional.
| Feel free to disagree.

No, I don't disagree, the principle is admirable.  My claim is its
application is wrong.  I'll take this case as a point.  The feature was
removed based on the assumption that "most people don't work with large
datasets", so it was not worth having.  and by removing the feature we
are able to simplify things.

Now if the assumption turns out to be wrong, and some people actually
need to work with large datasets, and they require that funcionality,
Now to get the functionality back, MORE COMPLEXITY has to be added
against the simplified codebase.

This is usually an indicator that the simplification is misguided and it
because it does not judge the value of feature or the tradeoff
accurately.

--
Madhu