Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] feature creep. WAS: splitting cvs spells

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Andrew Stitt <afrayedknot AT thefrayedknot.armory.com>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] feature creep. WAS: splitting cvs spells
  • Date: Wed, 11 Oct 2006 02:02:26 -0700

On Wed, Oct 11, 2006 at 09:33:38AM +0200, Jens Laas wrote:
> (06.10.10 kl.09:22) Andrew skrev följande till sm-discuss AT lists.ibiblio.org:
>
> Thats certainly true. Still, it takes some effort to learn the API. Good
> documentation will help in learning "what it does", which is the important
> part here. (I am taking the viewpoint of the casual user that needs to
> understand how a spell works.)

It takes effort to learn any API. Having a simpler interface by
abstracting the complex parts out makes it easier to learn the API.

This again is demonstrated by a Bash vs C example. consider:

for file in *.tgz; do mv $file $(basename .tgz).tar.gz; done

I can write that half-asleep and it'll work the first time.

Writing the above in C is another matter. Certainly not something I can
do half-asleep and expect to work the first time. We're looking at
probably 20 lines of code minimum for something custom and hacky.


> >
> > You shouldn't need to know how the library function is implemented. Only
> > what it does. This is called abstraction. Abstraction is a cornerstone
> > of not just computer programming, but just *operating* a computer.
>
> Yes. Abstractions are powerful, and the whole basis of modern computer
> programming. But what im trying to get across is that abstractions
> inevitably requires effort of the reader.

And the lack of them typically requires even more to solve the same problems.

For example, without up_triggers gurus would have to put regular triggers
in a bunch of spells by hand. With up_triggers, in one place gurus can
accomplish the same thing with less effort because the api is actually
simpler and requires significantly less work. In fact, most of the time
the usage patterns are the same, so they just add one or two lines and
leave it indefinitly, when before they had to add a line to a bunch
of spells and know to add that line in future spells with the same
problem. The solution not only accomplishes the same thing, but it goes
above and beyond that by having additional advantages.

Perhaps you can you provide a concrete counterexample?

> If you've already spent the effort and learned the abstraction ("what it
> does") then all uses of the abstraction is helpful.
> But when you have not learned the abstractions (really the API) then it
> tends to get in the way (not always, but often enough).

If you spend time to learn, then things will be easy.
If you don't spend time to learn, then things will be hard.
Thats true of anything.

>
> As long as you are working within a common set of known abstractions, the
> abstractions are working for you. When you are plunged into a set of
> abstractions that are not known to you, they are a hindrance.
> When you've taken the effort to learn the new abstractions they start
> working for you again. But the casual user might not want to spend this
> effort, for whatever reason.

Like I said before, you dont have to know *all* the various library calls
and abstractions to be productive. Only a minimal subset, which is doesn't
change significantly and is easy to pick up. I've never heard anyone say
"DETAILS is too complicated! I cant figure it out".

Perhaps we can get somewhere if you point out some part of our api that
is difficult to grasp or excessive and we can make it better. Lacking
concrete examples this is just an exercise in debating semantics of
software engineering in general.

> >
> > Like I said, the simplifications done actually make things simpler and
> > easier for users to understand. I find it easier to look at one line of
> > code with an intuitive function name than looking at 10 lines of code
> > that does the same.
>
> Sometimes but not always. Predicting side-effects from an intuitive
> function name can be really hard.

Well, a key word in my statement was "intuitive" as in, "_intuitive_
function name". A function that has hard-to-predict side-effects is,
by definition, *not* intuitive.


> >
> >>
> >> BUT without developers we have no users :-).
> >
> > Most of the users who become developers seem to understand the benefits
> > of abstraction. I could be wrong though, maybe they all hate the grimoire
> > library concept.
>
> I hope they love it. I like the concept and the existance of the grimoire
> library.
>
> Just dont overdo it :-). Choosing the right things and the right way to do
> the abstractions is a hard task. Noone can be expected to come up with the
> best way the first time.

Obviously. Most of the time the first solution isnt the one thats used.
Pretty much everything that gets in runs the guantlet. Many things don't
make it through. Moreover, when adding new functionality one of the
big concerns is always "how much development effort is this going to
require when updating". So yea, we already do what you're suggesting
and its pretty deep-rooted in our culture...


> I think the point I try to make is: "It is not always better to abstract
> than
> not to."

I've understood your point, but I lack any solid examples to support
your claim. So I remain unconvinced. Given my experience here and in the
workplace, I dont think abstraction is the problem.

Perhaps a different viewpoint: some problems should be solved and some
not at all.

-Andrew




Archive powered by MHonArc 2.6.24.

Top of Page