Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

More Re: [RSL/UHURU discussion]

 [1/2] from: joel:neely:fedex at: 25-May-2001 19:46

Hi, Volker, and everyone, Here's a bit more on the role of general libraries, stimulated by Volker's discussion.
> I even think the library is the more important part often. > But i read and experience building good libraries > is a very much harder part than special purpose code, >
This far we are in strong agreement...
> because with SPC you know what you want, > with libraries/frameworks you dont. >
...but not to this conclusion! I would state the difference this way: * With special-purpose code, I'm only focusing on the individual task at hand. My code may contain some dependencies on the peculiarities of the task at hand. * After I have accomplished enough similar tasks with special-purpose code, that experience starts to show me which parts are general and which are specific. I copy the general parts, make the specific parts into parameters, and I have something useful for my library. Of course, if I generalize/parameterize the wrong parts, or guess too quickly instead of using experience, I may very well create something not so useful. But trying to apply it will tell me where I got it wrong. It's just a part of the learning process.
> And function is only one part, usability is another. > You try to anticipate what it will be use for, > and that needs experience, experience and talent (i read:). >
And I'm confident that the members of the REBOL community have amassed sufficient experience to begin producing useful generalizations, even if it takes all of us ganging up on the problem.
> I think the core-libraries should be build in and carefully > balanced against each other, and cover the really important > parts. >
Agreed. I'm not proposing UHURU as a replacement for the built-in mezzanine functions.
> If it can't do that, and i have to work with perl-like > »collect your system first«, a large part of Carls > promises failed. >
Here I must disagree. If Carl had built something that only Carl could understand and use effectively, then I'd call *THAT* a failure. But I believe that Carl (and company) have built a foundation that the rest of us can join together to build on top of, and I call such a foundation a success. Unfortunately, Carl only gets a ration of 24 hours per day, just like the rest of us. Therefore, I also believe that we "little people" can play our role in helping that successful foundation achieve fuller acceptance by contributing useful material to a community library. Even if some of it (or even if *all* of it) were not written to the same standards of elegance and conciseness that Carl could achieve (given unbounded time and other resources), that's better than not having it, isn't it?
> > ... If we fail to offer the newcomer to REBOL a large > > collection of existing code (both for the purpose of
<<quoted lines omitted: 13>>
> much more options, and they bloat the code clarity, > where a single char patch would be sufficient.
But that's precisely why I've suggested that an UHURU unit contain three distinct parts (within one file,for the convenience of the author): 1) the meta-data used by UHURU itself for indexing, tracing dependencies, searching, etc., 2) documentation, which I assumed would include the usage examples, and 3) the functional code itself. Since the example section wouldn't be embedded in (3), but would be in (2), there wouldn't be any need for commenting out, switches, bloat, or any of those enemies of "clarity".
> And, having customized a script for use gives a good > feeling specially to beginners... I think »you can touch > it« is a good message for rebol :) >
I apologize if I wasn't clear enough in the earlier post; when I said ... offer the newcomer to REBOL a large collection of existing code (both for the purpose of study *and* for immediate black-box re-use) ... I would assume that a beginner might very well (as part of that "purpose of study") take a function from the library, play with it, try changing things to see what happens, see if (s)he could improve performance in specific situations, and so on. Speaking for myself, that's how I learn a new language best -- taking samples, changing them, breaking them, fixing them, etc.
> i would say »to recreat, find or understand«. > And the last two are growing easy if there is nobody > skilled enough to collect, refactor and compress them. > no, the general creation has do be done by > We pay them for that ;-) >
Not nearly enough!
> I would prefer creating »standard examples« > instead of »standard libray«. > hm. what will i say with this?! Well - .. >
There's room enough for both! You work on the first, and some of the rest of us will work on the second. (And any time Carl provides a better solution than what's in the library, I'll be the first to say, "Here's a better way!") -jn- ------------------------------------------------------------ Programming languages: compact, powerful, simple ... Pick any two! joel'dot'neely'at'fedex'dot'com

 [2/2] from: gjones05::mail::orion::org at: 26-May-2001 7:39

From: "Joel Neely"
> There's room enough for both! You work on the first, and > some of the rest of us will work on the second. (And any > time Carl provides a better solution than what's in the > library, I'll be the first to say, "Here's a better way!")
I contemplated the two sides of the coin yesterday evening, and realized that the community does need both. A lot of my learning occurs just like Volker is describing. There are several FAQ's and How-To's spread around. Some of these contain positively golden nuggets. The problem I have currently, is that I remember running across a hint, but I can't remember where it was. Furthermore, given that I learn one thing, I forget another, I can't even remember who all is maintaining FAQ-ettes and How-To's. Like, I know that Allen's site has a /View FAQ, and some explanatory articles on select topics. Brett's site has distilled some of the knowledge farmed from the list. REBOL's site has various bits and bytes of documentation that is "spread around" (my characterization added for dramatic purposes ;), and the desktop has lead-ins to demos and sites with code examples. And, of course, the list is archived in total at escribe. And on, and on, ad infinitum, ad nauseum... But, wow, where was that reference to how to collect cgi HTTP posts that are larger than 4k? So, I have to start surfing. By the time I finished surfing, I usually could have figured it out myself. But, what a waste of effort. There is no unified location. Of course, I could ask the list, but, unless someone just happens to remember *exactly* where the snippet is, the answerer has to expend some time and energy to collect and answer. And, of course, the same question gets asked time and time again, because it *is* a good question. What Volker describes would be like a super-FAQ/HowTo. It would be a very nice addition to the community, but it is a project with a different scope than the RSL/UHURU project in my mind. (Aside: scary thought about what resides in my mind! ;) If RT dedicated one official page of reference links (like the page) that were also kept up-to-date and were organized, the problem might not be so bad. The only other short-term solution would be to have our own special purpose REBOL sites search engine (Hey, yet another REBsite). But I think the grand-unified Volker creation would be better in the long run --- a long standing, current, up-to-date, organized repository of snippets/howtos/etc. I know that this monlogue has drifted way off topic, but not really, though, because Volker has a great idea that is being diluted by being included in this library thread. Yes, Joel, we need both solutions. May I get another cup of coffee? Maybe I've had enough already! --Scott Jones

  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted