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: Jens Laas <jens.laas AT data.slu.se>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] feature creep. WAS: splitting cvs spells
  • Date: Wed, 11 Oct 2006 09:33:38 +0200 (CEST)

(06.10.10 kl.09:22) Andrew skrev följande till sm-discuss AT lists.ibiblio.org:

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

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


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


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.

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.


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.

Sometimes but not always. Predicting side-effects from an intuitive function name can be really hard.



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.

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




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.

Never mind. It is probably impractical anyways.

This was an interesting discussion but I think we're fairly close to getting off topic. And the last thing I want to do is discourage you guys.

Thanks,
Jens


-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 |
-------------------------------------------------------------------------
_______________________________________________
SM-Discuss mailing list
SM-Discuss AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/sm-discuss


-----------------------------------------------------------------------
'In theory, there is no difference between theory and practice.
But, in practice, there is.'
-----------------------------------------------------------------------
Jens Låås Email: jens.laas AT data.slu.se
Department of Computer Services, SLU Phone: +46 18 67 35 15
Vindbrovägen 1
P.O. Box 7079
S-750 07 Uppsala
SWEDEN
-----------------------------------------------------------------------




Archive powered by MHonArc 2.6.24.

Top of Page