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 <afrayedknot AT thefrayedknot.armory.com>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] feature creep. WAS: splitting cvs spells
  • Date: Tue, 10 Oct 2006 09:22:04 -0700

On Tue, Oct 10, 2006 at 10:55:58AM +0200, Jens Laas wrote:
> (06.10.09 kl.08:42) Andrew Stitt skrev följande till
> sm-discuss AT lists.ibibl...:
>
> >
> > Well, Ironically the main reason to move stuff to libraries is to
> > simplify spells.
>
> I understand and agree, to a point. Every time something is moved into a
> function, you increase the level of indirection. If you know the interface
> of the function this will be a simplification. If you do not know the
> interface this increases the time to understand. You have to hunt down the
> implementation of the function and read what it does.

I think you're extrapolating your example a bit too far.

I also think what you're really getting at is we need better documentation.

Theres a distinction between "what it does" and "how it does it".

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.

When you run ls, do you know precisely what it does? Do you know what
system calls it makes? How those system calls are implemented? What
the filesystem is doing on your disk to store that information? How the
kernel is caching it for you? I don't know all of it, most people
don't. But they can still use ls. If you actually look at all the pieces
involved, its incredibly complex, but nobody says "ls is too complicated".

Do you know how "optional_depends" is implemented? Most people don't,
nor do they need to. Everyone uses it. They know what it does and how
to use it. Its got a simple description, and thats all that matters.
If the interface is created correctly, you shouldn't need to know how
it works. You just "press the button" and it works.

Similarly, take any high level language and compare it with a low level
language, like C. In (say) bash, theres all these layers of indirection
(cause its a high level language). In C theres a bunch of really low
level interfaces that connect directly to the kernel. You can typically
do the same things in bash with less code than in C.* Most people find
programming in bash easier and simpler than C, yet, its got more layers
of indirection between it and the hardware/os than C does.

In C it generally takes 3 lines of code to create a file, put something in
it and close the file. In bash its one line (echo foo > bar).

So more layers of indirection != more complicated harder to learn. Often
times the abstraction reduces the amount of stuff you need to know. And
thats the point.

Nor do you need to know the full api, only the pieces that matter. For the
vast majority of things going on, you dont need to use any super special
library functions. Most spells dont do fancy stuff. The complicated
stuff is what the main developers work on, for the average person, the
vast majority of spells are simple and require no special effort
to understand beyond the basic interface we've always had.


* C is faster and can do things bash can't, here we're looking at the things
that bash can do that C can also do.


>
> So for developers moving stuff to libraries is a good thing, and a
> simplification. Not necessarily for users.

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.

>
> 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.

>
> >
> > The challenge is to identify whats really necessary, and to make the
> > interface to that both simple and general enough to be re-usable later
> > for other problems.
> >
> > The real dichotomy seems to be "necessary" features vs "cause it'd be
> > cool" features. Can you be more specific on where you draw that line?
>
> No. A thought though: maybe we could separate the basic build and the
> separate advanced logic that does the "smart" build. The basic build
> should work by itself if every dependency (explicit or implicit) is met.

Im not sure I follow or even see how this isn't just another abstraction.

-Andrew

--
_________________________________________________________________________
| Andrew D. Stitt | acedit at armory.com | astitt at sourcemage.org |
| irc: afrayedknot | Sorcery Team Lead | ftp://t.armory.com/ |
| 1024D/D39B096C | 76E4 728A 04EE 62B2 A09A 96D7 4D9E 239B D39B 096C |
-------------------------------------------------------------------------




Archive powered by MHonArc 2.6.24.

Top of Page