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

RSL: Rebol Standard Library

 [1/44] from: m:koopmans2:chello:nl at: 23-May-2001 14:13


Proposal: Why not create the Rebol Standard Library (RSL)? As a community we can add to the strength of Rebol by adding a free standard lib, free as in the BSD or MIT license What we have so far (at least what I know/use, please add) - MySQL c mapping and native Rebol protocol - eRebol = rebol Server pages - Rugby - Design by contract - Enhanced help - Localization - Various VID styles (Win 95 skinning etc.) - Document generator (thanks Chris!) - High order functions - Rebol Web Server (but where?) As apps / components we have / should have - RIM - Rebol Chat - Rebol IRC - Rebol P2P presence provider - Rebol File sharing What we need: the RSL committee that makes releases of the RSL and provides hosting. Scripts!!! Anyone? --Maarten

 [2/44] from: joel:neely:fedex at: 23-May-2001 14:27


Hi, Maarten, Maarten Koopmans wrote:
> Proposal: > > Why not create the Rebol Standard Library (RSL)? > > As a community we can add to the strength of Rebol by adding > a free standard lib, free as in the BSD or MIT license >
...
> What we need: the RSL committee that makes releases of the > RSL and provides hosting. > Scripts!!! >
I submit that we need more than just "a standard library". Earlier this month, (8-9 May) we had a thread entitled Enabling the REBOL Community , which discussed the value to REBOL (the language, the company, and the community) of having the following: 1) A library of reusable code "units" 2) A standard taxonomy (e.g., logical structure) of such units. 3) Conventions for how the source code for such units should be structured. 4) Conventions for how such units are to be incorporated into new code under development. 5) Servers (plural!) which host identical copies of the entire library using the same taxonomic structure. 6) Client and server code that implements all of the above. I assume we want all of the above to be REBOL-centric. That means that -- by definition -- we reinvent some wheels in order to have REBOL-brand wheels. However, to avoid re-conceiving what a wheel *IS*, I recommend that we look at CPAN (and any other similar examples anyone wants to propose) for ideas on how the issues of functionality, communication, code base management, etc. might be addressed. I'll write a subsequent note to illustrate the kinds of question I suggest we address in (3) and (4).
> What we need: the RSL committee that makes releases of the > RSL and provides hosting. >
I'm willing to participate in all of the above, although I have limited time to spend on actually administering a publicly-accessible server at the present. -jn-

 [3/44] from: m:koopmans2:chello:nl at: 23-May-2001 22:16


Ah, well Allen Kamp offered to join as well, so there is three of us. My main concern is that we have a situation of talking only. My initial approach would be: - Honor al of your points below. - Take existing, proven, widely used Rebol code, put that into a standard form, archive it as a .rip and publish that. Enhance it based on feature requests. Perhaps we should divide some topic areas, like networking, software engineering, View, ... What do you think? --Maarten

 [4/44] from: chris:starforge at: 23-May-2001 21:48


#23-May-01# Message from *Joel Neely*: Hi Joel,
>> What we need: the RSL committee that makes releases of the >> RSL and provides hosting. >> > I'm willing to participate in all of the above, although I > have limited time to spend on actually administering a > publicly-accessible server at the present.
I have a server with 100Mb space and 5Gb/Month transfer. Provided that we can get this to a point where the project would be a realisable concern, I can devote some time to the creation and maintenance of a "RSL" (or whatever) repositry on there. Chris -- New sig in the works Explorer 2260, Designer and Coder http://www.starforge.co.uk -- The Scripture of the Master Programmer [Principals 1:64] If at first you don't confuse, explain again in opcodes.

 [5/44] from: ryan:christiansen:intellisol at: 23-May-2001 16:17


Will the library consist of entire scripts? or simply functions? I'd like to see a library of stand-alone functions which can be used as the building blocks for larger projects. "Maarten Koopmans" To: <[rebol-list--rebol--com]> <m.koopmans2@ cc: chello.nl> Subject: [REBOL] Re: RSL: Rebol Standard Library Sent by: rebol-bounce@ rebol.com 05/23/2001 03:16 PM Please respond to rebol-list Ah, well Allen Kamp offered to join as well, so there is three of us. My main concern is that we have a situation of talking only. My initial approach would be: - Honor al of your points below. - Take existing, proven, widely used Rebol code, put that into a standard form, archive it as a .rip and publish that. Enhance it based on feature requests. Perhaps we should divide some topic areas, like networking, software engineering, View, ... What do you think? --Maarten

 [6/44] from: m:koopmans2:chello:nl at: 23-May-2001 23:15


I have given the idea some thought again and have concluded that RSL may not be a good idea. Good things don't come from a standard but from the fact that a lot of people use them. What is much more important is the fact that we, Rebollians, create great code and share that in any way. Heavily used code will be a defacto standard. Since the active community is pretty small, I think for now I / we should focus on coding, coding,coding. That's an individual responsibility of each and every one of us. If you want this technology to succeed: - Spread the word - Buy the license - Write the scripts - Share your stuff Then what will be the RSL? The code that is most widely used. Perhaps we should use the script library as our repository (it worked or Rugby) and announce on this list. Thanks, Maarten

 [7/44] from: ryan::christiansen::intellisol::com at: 23-May-2001 16:24


I have a server with 500MB and 27GB/month transfer available for this, also. MySQL is installed. I also have a domain that is just itching for something useful: dangeroustechnology.com Chris <[chris--starfo] To: [rebol-list--rebol--com] rge.co.uk> cc: Sent by: Subject: [REBOL] Re: RSL: Rebol Standard Library rebol-bounce@ rebol.com 05/23/2001 04:48 PM Please respond to rebol-list #23-May-01# Message from *Joel Neely*: Hi Joel,
>> What we need: the RSL committee that makes releases of the >> RSL and provides hosting. >> > I'm willing to participate in all of the above, although I > have limited time to spend on actually administering a > publicly-accessible server at the present.
I have a server with 100Mb space and 5Gb/Month transfer. Provided that we can get this to a point where the project would be a realisable concern, I can devote some time to the creation and maintenance of a "RSL" (or whatever) repositry on there. Chris -- New sig in the works Explorer 2260, Designer and Coder http://www.starforge.co.uk -- The Scripture of the Master Programmer [Principals 1:64] If at first you don't confuse, explain again in opcodes.

 [8/44] from: ptretter:charter at: 23-May-2001 21:41


I agree with the direction RT is headed in. In fact, alot of the things I said would happen have /View is free now. And guess what I immediately bought /Pro. I am a happy person for the purchase. Additionally, I even chatted with Carl in Realtime. How many people get the opportunity to do that with their language founders (Thanks Carl). I agree with the language not being open source. I work for EDS and support large enterprise networks. I can tell you that open source is not a mechanism that top corporate execs care to indulge. It implies lack of support and organization. Thats why companies like Microsoft continue to flourish with their products. So for better or worse at least at this time it appears that RT is listening to what we want - at least any long time member of this list understands that by now. And I feel compassionate about the direction they will take given that very fact. So go REBOL go! Paul Tretter

 [9/44] from: gschwarz:netconnect:au at: 24-May-2001 13:54


Paul you said it well. And to quote from Slashdot "consistency comes at the price of openess. That's what REBOL is going after. A worthy goal." Regards, Greg

 [10/44] from: allen:aussieweb:au at: 24-May-2001 13:16


----- Original Message ----- From: "Paul Tretter" <[ptretter--charter--net]> To: <[rebol-list--rebol--com]> Sent: Thursday, May 24, 2001 12:41 PM Subject: [REBOL] Re: RSL: Rebol Standard Library
> I agree with the direction RT is headed in. In fact, alot of the things I > said would happen have /View is free now. And guess what I immediately > bought /Pro. I am a happy person for the purchase. Additionally, I even > chatted with Carl in Realtime. How many people get the opportunity to do > that with their language founders (Thanks Carl). I agree with the
language
> not being open source. I work for EDS and support large enterprise > networks.
I've noticed a few of the regulars are working for EDS. It is good to see such support for REBOL. Cheers, Allen K

 [11/44] from: al:bri:xtra at: 24-May-2001 19:03


I'm for it as well. Andrew Martin ICQ: 26227169 [new Rebol/eText site soon!]

 [12/44] from: chris:starforge:demon at: 24-May-2001 10:07


Paul Tretter wrote:
> I agree with the direction RT is headed in. In fact, alot of the things I > said would happen have /View is free now. And guess what I immediately
<<quoted lines omitted: 9>>
> list understands that by now. And I feel compassionate about the direction > they will take given that very fact. So go REBOL go!
For one, what exactly does this have to do with the subject? We were talking about a standard library of sources developed by the community, for the community. NOT open sourcing REBOL for goodness sake. Has anyone here even MENTIONED open sourcing REBOL recently? No. There have been complaints about the fact that the "free" on the website is not quite the free that most people understand it to be (ie: everyone thought "free" means "no charge, for anything" when it really means free for personal use ) and the licensing was changed without even telling the people using the language. But the whole issue of open source/GPL wasn't even a factor until it was mentioned by Holger. People had assumed /core was free as in free beer, no one has been yelling for RT to release REBOL as OSS for quite some time. All we need now is for someone to mention the nazis, at least then the whole thread can be considered dead.. Chris

 [13/44] from: al:bri:xtra at: 24-May-2001 21:50


> All we need now is for someone to mention the nazis, at least then the
whole thread can be considered dead.. I reckon someone should open source code Nazi party policy, and sell it for beer hall money... Andrew Martin ICQ: 26227169 [new Rebol/eText site soon!]

 [14/44] from: chris:starforge:demon at: 24-May-2001 11:12


Andrew Martin wrote:
>>All we need now is for someone to mention the nazis, at least then the >> > whole thread can be considered dead.. > > I reckon someone should open source code Nazi party policy, and sell it for > beer hall money...
LOL! :))) Chris

 [15/44] from: gjones05:mail:orion at: 24-May-2001 5:43


> Andrew Martin wrote: >>All we need now is for someone to mention the nazis, at least then the >>whole thread can be considered dead..
First, one must make a crack about AOL, then the Nazi's. ;-) I can't speak for Paul but I suspect he just "replied" to the wrong thread. The RSL thread is an important thread that shouldn't be prematurely killed. --Scott Jones

 [16/44] from: ptretter:charter at: 24-May-2001 6:18


Actually, you correct. I must have clicked the wrong email when I made the reply. This does have absolutely nothing to do with the subject. Actually, meant to post it to some Slashdot reference if I recall. Paul Tretter

 [17/44] from: joel:neely:fedex at: 24-May-2001 6:30


Chris wrote:
> Paul Tretter wrote: > > > I agree with the direction RT is headed in... > > For one, what exactly does this have to do with the subject? > We were talking about a standard library of sources developed > by the community, for the community. NOT open sourcing REBOL > for goodness sake. >
Well said, Chris!
> All we need now is for someone to mention the nazis, at > least then the whole thread can be considered dead.. >
As far as the issues of a community-supported code library versus "open sourcing REBOL", I have to agree that I did nazi any relationship between them... OOOPS, I KILLED IT! ;-) -jn- -- ------------------------------------------------------------ Programming languages: compact, powerful, simple ... Pick any two! joel'dot'neely'at'fedex'dot'com

 [18/44] from: joel:neely:fedex at: 24-May-2001 7:40


Hi, Maarten, (or anyone who's interested...) Here's the promised follow-on... I apologize for the length of the introduction, which is there for anyone who wonders why I don't just want to say do http://some.server.org/name-I-found-by-magic.r and hope for the best. ;-) After the preamble, I give a hypothetical example of how I imagine a shared library might work in practice. I am proposing a usage story as a starting point for discussion of the features that such a service/system would have. As far as I am concerned, everyone's input is VERY welcome. Let me make one request -- if anyone sees anything in the ongoing discussion not to his/her taste, please feel free to say so, BUT in the form of an explanation of why you don't think something will work well, along with your proposal of an alternate solution (i.e., positive and constructive). -jn- Maarten Koopmans wrote:
> Proposal: > > Why not create the Rebol Standard Library (RSL)? >
My perception is that, up to this point, code sharing in REBOL has taken one of the two following forms: 1) Someone writes a "chunk" of REBOL code and places it in a publicly-accessible place, including: 1.1) A single function definition in an email message. 1.2) A collection of related functions, defined in a single source file, placed on an http/ftp server. 1.3) A collection of code, wrapped in an object to protect the global namespace, placed on a server. 1.4) ...etc... 2) Someone "publishes" availability of a REBOL fragment, function(s), object(s), or script(s) via the WWR. An access to that published chunk causes it to be mirrored by View in a subdirectory tree that is a combination of: 2.1) Where REBOL is installed on the local system, 2.2) Which RebSite offered the chunk, and 2.3) Where in the directory tree under that RebSite's document root the chunk came from. Neither of these provised a scalable solution to certain issues that I think are critical success factors for a community library: a) A way to understand where to look for something; b) A way to know where to look if the answer to (a) is not available, overloaded, responding slowly, etc.; c) A way to mirror locally just the parts of the library that I need for a specific task; d) A way to obtain quickly the parts under (c) that I need for a specific task at hand; e) A way to verify whether my local copy of stuff is up to date, and to refresh any/only those that are not, and to do so automatically; f) A set of conventions that provide high confidence that I can use a newly-obtained unit without: f.a) Having to read the complete source to figure out the (possibly unique) usage interface for that unit; f.b) Having collisions in the global (or other...) namespace; f.c) Having to look elsewhere for appropriate docs. As a concrete example (PLEASE NOTE: HYPOTHETICAL!) one could use the following conventions, similar to those we discussed in connection with UHURU (Universal Home for Useful REBOL Units, Unit Handling Utility for REBOL Users, or whatever...) Let's imagine that: 1) A local box can configure a directory as its "UHURU root" directory. All source from the standard/shared/UHURU lib lives in a directory tree under that root. Let's imagine that on my box that directory is /usr/local/bin/reblib . 2) The directory tree matches the concept tree of the library. 3) I want to use a function from a published unit of text file utilities: one that reads a tab-delimited file and creates an HTML table from it. 4) To find that function, I browse an on-line description of the concept tree and find that /text/conversion/del-ascii-html defines an object containing such a function, named tdf-to-table 5) I go to an interactive console and enter UHURU/install /text/conversion/del-ascii-html Unknown to me, that source file depends on another unit located at /text/conversion/delimited-ascii However, the install routine is able to determine that fact from markup in the one I asked for, checks to see that I do (or do not) already have it installed, and installs if if necessary. 6) As a result of the installation, my local box now contains the files /usr/local/bin/reblib/del-ascii-html.r /usr/local/bin/reblib/del-ascii-html.html where the first is a usable code module and the second is documentation for all of the functions it defines, samples of usage, etc. (Any other depended-upon units are likewise represented in the appropriate places.) 7) I am now writing code which needs that capability. Inside one of my source files make-phone-book.r , I say #!/usr/local/bin/rebol REBOL [ ; ... details omitted ... ] make object! [ ; ... more details omitted ... tdf-tbl: UHURU/import del-ascii-html.r [tdf-to-table] ; ... etc ... run: func [filename [string! file!] ...] [ print tdf-tbl/width to-file filename 600 ... ] run %dept-phones.txt ] This creates the word TDF-TBL *within the context* of the object I am defining. Neither TDF-TBL, nor anything that the sourcefile del-ascii-html.r defines, nor anything that del-ascii-html.r imports, are inserted into the global namespace. My subsequent code is now free to use TDF-TBL as an internal function. 8) Some time later, I see an announcement on a mailing list that there is a new version of del-ascii-html available that has both a new, highly-useful refinement added to tdf-to-table, and also adds three more nice functions. I go to a console session and type UHURU/update /text/conversion/del-ascii-html after which the latest-and-greatest is on my local box. I do this without fear, because: 8.1) All contributors agree not to break or remove functions that are already in published units, therefore the TDF-TO-TABLE function in del-ascii-html.r still does what it used to. 8.2) Even though the new version contains more code, I am only IMPORTing one function, therefore I don't worry about code bloat. The ones I don't use don't show up in my namespace. The fact that dependencies are automatically resolved by INSTALL lets unit developers build finer-grained units, instead of building giant kitchen-sink files with every good idea piled in "just in case". 8.3) Even though the new version contains LOTS of great documentation and examples, I don't worry about taking up run-time memory (or time to read through it), because INSTALL splits all that stuff out of the down- loaded file and creates the separate .html file above. The .r file is now lean and mean. I could go on imagining other usage stories, but that's more than enough for now! Let me imagine, in closing, that the file I download satisfies the implied requirements from above by looking something like this: <UHURU version="1.2"> <UHURU:unit name="del-ascii-html" ver="2.1" path="/text/conversion" /> <UHURU:keywords> ASCII HTML comma tab convert text conversion </UHURU:keywords> <UHURU:depends-on> /text/conversion/delimited-ascii </UHURU:depends-on> <UHURU:doc type="html" /> </UHURU> <html> <head> <title>del-ascii-html: Delimited ASCII to HTML conversions</title> </head> <body> ... lots of useful documentation ... </body> </html> REBOL [ .... ] make UHURU/unit [ ... tdf-to-table: func [...][...] ... ] which contains all the information and content to fulfill the requirements of the imaginary story above. As alternatives, the documentation could have been written in XML, using a set of <UHURU:...> tags, which the installer expands into the appropriate HTML, complete with standard formatting/boilerplate. Of course, I'd expect for the MAKE-SPEC format to be supported as well. ;-) -jn-

 [19/44] from: chris:starforge:demon at: 24-May-2001 14:32


Joel Neely wrote:
> <UHURU version="1.2"> > <UHURU:unit name="del-ascii-html"
<<quoted lines omitted: 25>>
> ... > ]
100% agreement up to this point. IMO <UHURU ...>..</UHURU> is not required - look at the REBOL header, we already have File (which is UHURU:unit name) and Version. By extending the header so we have, say, a standard like: REBOL [ Title: "del-ascii-html: Delimited ASCII to HTML conversions" Version: 2.1 File: %del-ascii-html.r .. other standard fields in here ... UHURU-Path: %/text/conversion/ UHURU-Keywords: ["ASCII" "HTML" "comma" "tab" "convert" "text" "conversion"] UHURU-depends: %/text/conversion/delimited-ascii UHURU-doc: %del-ascii-html.html ] This way scripts could use their UHURU (we really need a better acronym I'm afraid ;)) information as metadata and the header processing the UHURU handling scripts would need is already built into REBOL. I'd even suggest allowing UHURU-doc to be either a file, in which case the file is obtained, or the keyword "auto" in which case code like my reboldoc is used to extract the html documentation from the source itself (which IMO is a lot easier on the programmer, and thus more likely to be used properly - there's only one set of docs, the docs in the code, to maintain rather than two.) Chris

 [20/44] from: chris:starforge:demon at: 24-May-2001 14:56


Chris wrote:
> This way scripts could use their UHURU (we really need a better acronym > I'm afraid ;))
On that subject (no tm check done on these BTW..) ROAST - REBOL Open Access Script Toolkit ROSE - REBOL Open Script Extension NARSIL - Network Assisted Rebol ScrIpt Library Chris

 [21/44] from: gjones05:mail:orion at: 24-May-2001 10:38


Hi, Joel, I'm not including any of your message for the sake of download brevity. Those who need the original are referred to: http://www.escribe.com/internet/rebol/m9432.html I am in agreement with the general scheme that you have laid out. Pardon me in advance if I have misunderstood anything you have said, but here are some additional thoughts (in regard to your posting the other day and today): I like the idea of careful namespace protection and importing only the aspects of the implementation needed. These ideas are smart and efficient. The way in which versioning is managed is also important. Tcl (and I'm sure numerous other languages) allows for a flexible use of packages, and in fact uses the keyword package. Tcl has several refinements of this command. One refinement is "package require" type statement that can specify a specific version of module. Tcl looks in a configured path for the package and halts if that package in that version is not available. Tcl folks have done a fair amount of thinking about packages, and I suspect that we could borrow the best from the them and leave the rest. Link to on-line man pages that cover the package command: http://dev.scriptics.com/man/tcl8.3.2/TclCmd/package.htm I can see packages (or modules or what-ever form of generic name) being either literally included by the application author (like an automatic form of a cut and paste) after being loaded into the public path or that the application makes reference to a package that is to be included in the public path. If not there, then the user's instance of the application requests the package piece from the Internet store. Tcl does not include any simple, (semi-)automated method for retrieving a package if it is not available locally (it could be done; it's just not done simply). Here is where REBOL clearly excels. However, with the flexibility and power for an application to look on the net for a required package, comes the responsibility that the "right" package is delivered (or sub-component, as you have proposed). I agree that package naming should be consistent from version to version, but as in all things, deprecation and/or extension will occur that will hinder compatibility. The only (non-exclusive) options are to give the module a new name or to make version use an explicitly configurable option. Say, for example, a package had versions 1.0, 1.1, and 1.2 that where basically backwards compatible, but that version 2.0 required a change in implementation that could not be hidden. Older applications might still need live access to the older versions of the package; whereas, newer applications would need access to newer versions. As long as the various stable versions were always available, an application could specify that "only" a specific version could be used. Tcl (if I recall correctly) does not allow this sort of flexibility; it only allows for a minimum package version allowed (if I'm wrong, sorry Tcl'ers). I think a robust package managment system could allow for a robust variation in how applications are woven together. Yes, increased complexity, but I believe that it is manageable if done from the outset. Merely/only *replacing* older packages with newer packages opens up the kind of problems that Microsoft developed with their method of redistributable libraries. I am not terribly familiar with CVS, but I guess the ideal method taps into a CVS tree to either get the right version and/or the most recent version, depending on the application developers needs and intentions. Whew, did that make any sense, I ask myself while chewing on lead paint chips?!?! Hopefully, the essence shines through my sleep-deprived prose. The other point that has come readily to mind is that these modules/packages should have their own regression testing section available. This was a requirement at one time for the "Tcl Standard Library," which allowed developers of more complex applications to have these tests available for whole-project regression testing. I thought this was a really slick idea, as a way to be sure that processes are not interfering with one another and invalidating the coding logic. Just some incoherent thoughts. May I be excused? ;-) Thanks for the thoughtful contributions to date from all parties. Nice work, **as usual**, Joel. ;-) --Scott Jones

 [22/44] from: joel:neely:fedex at: 24-May-2001 11:43


Hi, Chris, Chris wrote:
> 100% agreement up to this point. IMO <UHURU ...>..</UHURU> is not > required - look at the REBOL header, we already have File (which is > UHURU:unit name) and Version. By extending the header so we have, > say, a standard like: >
In my desire not to inflict a war-and-peace email on the list, I left out some of the rationale... The reasons I've suggested the <UHURU ...>...</UHURU> part are: 1) I assumed we'd want to keep all of the library-related stuff *out of* the header, so as not to conflict with any plans or future developments RT may have/make with header content. 2) I assuemd we'd want to keep "meta-data" in the UHURU XML so that we could modify or expand it without worrying about that increasing load times of modules being utilized. (The meta-stuff would get stripped out by INSTALL, so that it wouldn't be in the .r file. 3) We already have PARSE-XML, so the effort to implement the <UHURU...> stuff should be minimal. 4) We might want to drive other tools (e.g., a keyword-search tool) with meta-data. By putting the <UHURU ...> stuff first, such tools could remain oblivious to all other content. 5) I assumed that a unit file would be maintained as a single file by the developer. There would still be only one place to go to perform ongoing modification on the code, docs, and meta-data.
> This way scripts could use their UHURU (we really need a better > acronym I'm afraid ;)) ... >
StarTrek Classic fans everywhere are priming their flamethrowers! ;-)
> ... information as metadata and the header processing the UHURU > handling scripts would need is already built into REBOL. >
Everything to parse the <UHURU...> stuff *is* already built into REBOL (see (3) above), but the manipulation of the content would be added code in any case. The advantage of XML over the REBOL header block is that we get a conventional syntax for complex data structures for free (assuming one already knows XML).
> I'd even suggest allowing UHURU-doc to be either a file, in > which case the file is obtained, or the keyword "auto" in
<<quoted lines omitted: 3>>
> - there's only one set of docs, the docs in the code, to > maintain rather than two.)
As mentioned above, I'd like to see if we can avoid burdening the loadable REBOL code with non-executable content, but at the same time make it easy to supply that *with* the code. For example, a page-long narrative on a non-trivial object, along with usage samples, would be quite a bit of overhead to read through just to load the object def itself, IMHO. Anyway, those were my assumptions and preferences. I'm certainly open to discussion leading to something we can all live with and use effectively. -jn-

 [23/44] from: chris:starforge at: 24-May-2001 17:53


#24-May-01# Message from *GS Jones*: Hi GS,
> believe that it is manageable if done from the outset. Merely/only > *replacing* older packages with newer packages opens up the kind of
<<quoted lines omitted: 3>>
> most recent version, depending on the application developers needs and > intentions.
Good points, especially that about versioning - the last thing we we want is to be the creators of out own "DLL Hell". As you say, allowing the required version to be explicitly specified is a very good idea, but I would say that we need a bit of flexibility, for example: - Requesting Foo vN.M will return exactly that version - Requesting Foo vN will return the latest revision of version N of Foo - Requesting Foo will return the latest revision of the latest version. If the specification of the system demands that revisions must be backwards compatible while versions do not need to be this will allow people to obtain the latest bugfix of a package without necessarily knowing the revision required. As for using cvs... As a unix programmer I'm all for that idea, but it would be conterintuitive for a lot of Rebolutionaries. cvs is not the simplest of systems for people to learn, and if this is to be a sucess I think it needs to be hassle free. A secondary problem is that setting up cvs to do this requires one or more cvs servers, keeping them all in synch could cause serious logistical problems. I'd suggest that a better solution would be a REBOL script to do all this: REBOL has all the facilities built in to do what we need, and there is no need for a special server: the files could be obtained from a webserver using read. This has the nice side effect that it would be possible to synch the mirrors very easily - there's no need to do checkouts and checkins all over the place. Something as simple as a couple of ftp sessions (or even a cron triggered script) could do it. Of course, this means we actually have to write this thing :) Chris -- New sig in the works Explorer 2260, Designer and Coder http://www.starforge.co.uk -- If you're not very clever you should be conciliatory. -- Benjamin Disraeli

 [24/44] from: gparks:revisioninc at: 24-May-2001 11:01


<snip> > > This way scripts could use their UHURU (we really need a better > acronym I'm afraid ;)) ... >
StarTrek Classic fans everywhere are priming their flamethrowers! ;-) I think her name was spelled differently:) Actually I think Uhuru means freedom in some African language. It was the rallying cry of the Zulu warriors when they were trying to expel Dutch colonialists...

 [25/44] from: gjones05:mail:orion at: 24-May-2001 12:26


Link to message from: "Chris" http://www.escribe.com/internet/rebol/m9449.html Yes, Chris, you have read my mind even more accurately than I was thinking the thoughts! You have more clearly expressed what I was trying to say about the versioning control. Thanks. And as far as CVS, per se, or a system written in REBOL that gives REBOLite application developers an Internet-accessible, version tree that can be synced across mirrors, yes, you have the right idea there, too. And as far as writing the code, you do such a good job of reading my mind (better than I do of "thinking" my mind), let me think the thoughts, and you can just do the typing! And, of course, Joel will make sure that the code is properly refactored and encapsulated. ;-) Seriously, thanks for seeing what I was trying to say, and making it make more sense. --Scott Jones

 [26/44] from: gjones05:mail:orion at: 24-May-2001 12:31


> From: Chris > > This way scripts could use their UHURU (we really need a better > > acronym I'm afraid ;)) ... > >
From: "Grant Parks"
> StarTrek Classic fans everywhere are priming their flamethrowers! > ;-) > > I think her name was spelled differently:) Actually I think Uhuru
means
> "freedom" in some African language. It was the rallying cry of the
Zulu
> warriors when they were trying to expel Dutch colonialists...
From http://heasarc.gsfc.nasa.gov/docs/uhuru/uhuru.html ==== Uhuru, also known as the Small Astronomical Satellite 1 (SAS-1) was the first earth-orbiting mission dedicated entirely to celestial X-ray astronomy. It was launched on 12 December 1970 from the San Marco platform in Kenya. December 12 was the seventh anniversary of the Kenyan independence and in recognition of the hospitality of the Kenyan people, the operating satellite was named Uhuru, which is the Swahili word for freedom . The mission operated over two years and ended in March 1973. ==== Somehow Joel's acronym still seems appropriate, but hopefully the system will last longer than the satellite mission! --Scott Jones

 [27/44] from: chris:starforge at: 24-May-2001 19:21


#24-May-01# Message from *Joel Neely*: Hi Joel,
> In my desire not to inflict a war-and-peace email on the list, > I left out some of the rationale... > The reasons I've suggested the <UHURU ...>...</UHURU> part are: <snip>
I see. I was just exercising the REBOL equivalent of Occam's razor - all the features could be done using nothing but REBOL's internals. But if there are good reasons, as you outline here, an XML intro would serve the project better.
>> This way scripts could use their UHURU (we really need a better >> acronym I'm afraid ;)) ... > StarTrek Classic fans everywhere are priming their flamethrowers! > ;-)
Wasn't that Uhura? (Not a ST fan so..)
> As mentioned above, I'd like to see if we can avoid burdening the > loadable REBOL code with non-executable content, but at the same > time make it easy to supply that *with* the code. For example, > a page-long narrative on a non-trivial object, along with usage > samples, would be quite a bit of overhead to read through just > to load the object def itself, IMHO.
Hmm.. we're getting into Holy War subjects here ;) I guess stripped versions would be good, but as a heavy commenter the idea of commentless code is somewhat abhorrent ;)) Chris -- New sig in the works Explorer 2260, Designer and Coder http://www.starforge.co.uk -- There is only one thing in the world worse than being talked about, and that is not being talked about. -- Oscar Wilde

 [28/44] from: gjones05:mail:orion at: 24-May-2001 14:07


> From "Joel Neely": > > As mentioned above, I'd like to see if we can avoid burdening the
<<quoted lines omitted: 7>>
> versions would be good, but as a heavy commenter the idea of > commentless code is somewhat abhorrent ;))
I guess here, too, I would have to add what I'm envisioning (Chris, get ready with the telepathic powers so that you can translation for the rest of the readers ;-). I can envision circumstances where commented versions would be nice and uncommented versions would suffice. I one example, if a no-computer-literate consumer/user is running an application that needs to go to the Internet to get some functional component from the standard library, comments, just like unused components, would only serve to diminish bandwidth. If an error occurs and the app dies, this user would not be likely to persue the code. However, like some, if I were developing an app that used this functional component, the comments would be very helpful (at least for a partially demented person like myself). <alert type="feature bloat"> I could envision a mechanism, perhaps a flag, where this hypothetical central server would deliver the correct version based on some configurable feature or flag. </alert> Poor Joel is probably thinking, why did I ever restart this thread. And poor Maarten is probably thinking that this could have all been done very simply through LDC. And poor Chris is thinking does this guy really think I can read his mind? I'm really not in the know like many of you, so please don't hesitate to ask me to be quiet for a few minutes (hours/days). ;-) Thanks for staying tuned. --Scott Jones

 [29/44] from: joel:neely:fedex at: 24-May-2001 13:54


Hi, Grant, Grant Parks wrote:
> > StarTrek Classic fans everywhere are priming their flamethrowers! > > ;-) > > I think her name was spelled differently:) >
Uhura. Lame in-joke. Sorry.
> Actually I think Uhuru means > "freedom" in some African language. It was the rallying cry of the Zulu > warriors when they were trying to expel Dutch colonialists... >
Swahili, IIRC. That was actually the motivation for the name, as mentioned in the thread early this month. -jn-

 [30/44] from: chris:starforge at: 24-May-2001 20:47


#24-May-01# Message from *GS Jones*: Hi GS,
> I guess here, too, I would have to add what I'm envisioning (Chris, get > ready with the telepathic powers so that you can translation for the > rest of the readers ;-).
LOL :))
> <alert type="feature bloat"> > I could envision a mechanism, perhaps a flag, where this hypothetical > central server would deliver the correct version based on some > configurable feature or flag. > </alert>
In other words, keep two copies of the scripts on the server: one containing all the comments and code and one stripped version and indicate in the request which you require, for example: UHURU/install text/conversion/del-ascii-html devel to obtain the commented version. Leave of the devel and you just get the code withthe comments stripped. Maybe even UHURU/install text/conversion/del-ascii-html devel doc could be used to indicate that the development version and documentation should be installed, leave off the doc and you just get the commented code. Not bloat so much as redundancy. If there was a quick and easy way to strip comments from REBOl code, you could just get away with storing the commented version on the server: If a request came in for the stripped code you just run the file through the comment stripper as you send it. If a request came in for the development version you just send the file as is. If a request came in for the developer version + docs then you could send the file and then use a doc generator to generate the docs (unless they have been pre-written of course). (The logical fourth option is to obtain the uncommented code + docs - although I guess this is only attractive to Real Programmers (who probably wouldn't be using REBOL anyway)) In the absence of a fast and clean comment stripper though, storing both files plus an optional html doc would be the easiest, if rather wasteful, way to do this.
> Poor Joel is probably thinking, why did I ever restart this thread.
I missed this the first time around - I was too caught up in the license thread. I'll try to read through the discussion tomorrow at work, I don't have to pay by the second there! ;/
> very simply through LDC. And poor Chris is thinking does this guy really > think I can read his mind?
:) /me passes Scott a bottle of dried frog pills Chris -- New sig in the works Explorer 2260, Designer and Coder http://www.starforge.co.uk -- Main's Law: For every action there is an equal and opposite government program.

 [31/44] from: m:koopmans2:chello:nl at: 24-May-2001 22:25


Joe, Your descriptions conceptually matches the concept of ports in FreeBSD, which is quite sophisticated. I'd suggest Rebol as data format as well, we'd have data/code in one. --Maarten

 [32/44] from: gjones05:mail:orion at: 24-May-2001 15:55


From: "Chris"
> /me passes Scott a bottle of dried frog pills
LOL. Must be one of those uniquely British sayings. My sister has lived there 20+ years. I'll see if she has heard of it. =) --Scott Jones

 [33/44] from: lmecir:mbox:vol:cz at: 24-May-2001 23:54


Hi, wouldn't it be better to try to use only Rebol instead of XML/Rebol? As far as I know Rebol was designed to be able to do everything XML can do. Regards Ladislav

 [34/44] from: joel:neely:fedex at: 24-May-2001 16:56


Hi, folks... (Remind me never to get tied up in all-day meetings again...) Chris wrote:
> > <alert type="feature bloat"> > > I could envision a mechanism, perhaps a flag, where this
<<quoted lines omitted: 4>>
> one containing all the comments and code and one stripped > version and indicate in the request which you require...
Actually, what I was in my head (for those who can't read *MY* mind ;-) was a bit simpler, for some definitions of simpler ... I'm all for documentation, but I tend to view "comments" as covering (at least) three very different things: 1) internal comments about some implementation detail, useful for someone needing to understand the code itself, 2) the interface help/hints in function specs, useful for someone interactively asking for a reminder about the calling conventions, and 3) the kind of long-running-narrative-text descriptions that explain the intended usage of a library unit, including tutorials, examples, etc., useful to someone browsing the library or trying to understand usage of a unit, but not interested in the implementation details. I'd also observe that we *WANT* for (3) to be as big and detailed and feature-rich and example-laden as is needed to provide comprehensive, self-contained reference material. My imaginary description from earlier in the thread assumed that all of the above were present in the library unit file, but that (3) was in a separate section of the file, (instead of distributed throughout the code or contained within the REBOL header) so that the installation could split the file into the documentation part (browsable at will) and the loadable part (still containing whatever of (1) and (2) that the author deemed fit, but not containing the readme/reference/ etc. content of (3). It was a conjecture as to how to resolve these conflicting forces: 1) We want the loaded components to be lean and mean, 2) We want authors to be free to write as much reference material as necessary, 3) We want all of the above "in one place" at least for the purposes of deployment. -jn-

 [35/44] from: alan_otterstad:mikronvinyl at: 24-May-2001 15:05


ok....i'll bite.... hey Joe.... Don't get tied up in all day meetings ok??????? hehehe (sorry) alan

 [36/44] from: agem:crosswinds at: 25-May-2001 2:16


Thread sound a lot to conventional to me. I think, first we should use rebol. So why this smart-server-stuff? Carl shows us allways: put some files on the server, download a maker-script, do it, voila, there is what you want. Let the client do the work :) then we use rebol.. Carl says all the time: perl & smalltalk & java && needs learning all the good stuff (class-hierachis, pan-archives etc pp) before going productive. Years.. To use rebol you need only rebol & inspiration. With a highly structured big library we compete with this languages in their best field: giving jobs to highly skilled experts instead of power to users.. And we use rebol.. One internal rebol-rule is: if you re-use code, copy it! Thats the way [make something![..]] works: it does not use pretty structured information(class/object-style). It copies the old script (oops, object) and the old may change how it likes. New too. Also the organisation object/word and dir/file is similar. So, if i recycle a good script, i use my own copy, »bloating« or not. Copy it to script-dir, done. No installation-magics, no update-problems. Like [make %script.r »«] Because i use rebol, which is extremely expressiv. Rebol-code is data. for example [find (pick in feel 'engage] block!)] is a good base to enhance/change the feel-behavior. As long as the source is frozen, its much better than common oops »parent super dancing« IMHO. But, would it be considered to be part of the backward-compatibility-list? And, do we want to be that compatibility-aware? Its like freesing yourself to the old solution while i could build much better this two years later. Bloat again.. compatibility/library-sensitiv stuff should be done by the most skilled people and on only one place. Currently that happens well: on rebol.com . Last paragraph learned on slashdot ;-) Well, since we use rebol: Suggestion: script-database (oops, me? Yes:) - global index to »the world«: desktop can link pretty to scripts on different pages/servers. - good search-program there: fulltext, filenames, when posted, categories. hm. maybe we can index in future like related: [»has cgi?« 30% »clever argument handling« 67%] and use something like fuzzy logic for search? Presenting the user »all« known questions and getting his priorities for script-selection? - Unique global script-id's (checksums) if i want a script, i mean exactly that script! All others may break. - mirrors. If you want to mirror something send your indexes to the database. - Sophisticated diff. A colored diff tells much more to me than all version-infos. searching all projects on my machine and presenting me information about updates from the web with some gui-help to embed them. - some ranking/commenting for scripts and author? »script is broken, you need image by hand« »i like allans scripts. Give me stuff from him first« ..? i think »express« would do it more this way tahn with static early-iced library? hm. no cheap way to know :( and final, remember rebol means lightweight. If i really need that lot code cpan's/cvs's are meant for, first i check what i do wrong. chances are it's a thousand-wheeler.. Volker
>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 24.05.01, 21:47:19, schrieb Chris <[chris--starforge--co--uk]> zum Thema [REBOL] Re: [Fwd: Re: RSL: Rebol Standard Library]:

 [37/44] from: chris:starforge:demon at: 25-May-2001 10:44


GS Jones wrote:
> From: "Chris" > >>/me passes Scott a bottle of dried frog pills >> > > LOL. Must be one of those uniquely British sayings. My sister has > lived there 20+ years. I'll see if she has heard of it. =)
I doubt she will, unless she reads Terry Pratchett's Discworld books. In them, the Bursar at the Unseen University (the university at which most of the disc's wizards are trained) is utterly insane. One of the wizards came up with the idea that they could make the Bursar sane by making him halucinate that he was sane, this is done using the dried extracts of a deadly poisionous frog given to him in pill form. Hence the bottle of dried frog pills ;)) Chris

 [38/44] from: gscottjones:hot:mail at: 25-May-2001 7:18


Oh, definite email problems. Apparently my inbound emails are getting bounced before they hit my email provider. :-( Furthermore, the bounces apparently have caused me to become unsubscribed from the list. :-0 So on to my account salciously-named hotmail account =-\. Sorry if the other posts come through. ....
>>From: "Chris" >>>/me passes Scott a bottle of dried frog pills
<<quoted lines omitted: 13>>
>him in pill form. >Hence the bottle of dried frog pills ;))
This is a wonderfull stuff. Its kind of like doctoring in an "Alice and Wonderland" world. It also sounds like just the medicine I need! Thanks! I should call you Doctor Chris. --Scott Jones

 [39/44] from: joel:neely:fedex at: 25-May-2001 8:03


Hi, Volker, I guess everything I have to say can be summed up in these statements: 1) We agree (more than you seem to perceive) with respect to a smart-client-dumb-server strategy. I can't speak for anyone other than myself. 2) You seem to prefer to develop by cut-past-and-edit. I prefer to have the option of re-using code units that package generic functionality. Each of us should be able to program in his preferred style. I do have some more specific responses to point you raised in your email, but I'll cover them separately to avoid creating another war-and-peace post. -jn- -- ------------------------------------------------------------ Programming languages: compact, powerful, simple ... Pick any two! joel'dot'neely'at'fedex'dot'com

 [40/44] from: gjones05:mail:orion at: 25-May-2001 6:09


>> From: "Chris" >>>/me passes Scott a bottle of dried frog pills
<<quoted lines omitted: 13>>
> him in pill form. > Hence the bottle of dried frog pills ;))
This is a wonderfull stuff. Its kind of like doctoring in an "Alice and Wonderland" world. It also sounds like just the medicine I need! Thanks! I should call you Doctor Chris. --Scott Jones

 [41/44] from: joel:neely:fedex at: 25-May-2001 9:04


Hello, again, Volker, We simply have different perspectives on what makes a language learnable and what makes a programmer productive. -jn- Volker Nitsch wrote:
> perl & smalltalk & java && needs > learning all the good stuff > (class-hierachis, pan-archives etc pp) > before going productive. Years.. >
I'm sorry, but I simply don't believe this. I've only dabbled in Smalltalk, but I've used Perl and Jave extensively (along with a couple of dozen other languages during my career). My experience is that I can write "Hello, world!" in a new language with almost no learning time. If the language has features targeted toward a specific application area, and I'm already familiar with that area, I can begin writing code for those applications with very little learning time. When I start doing things that either fall outside the "sweet spot" of the language, or that fall outside my own existing knowledge of the application domain, I have to invest the time to learn something. That's true whether the "something" is the notation of the language, the capabilities of built-in language features, or the capabilities of a library. Perl is a very "rich" language, in the sense that Larry Wall built a huge (some would say bewildering ;-) set of features into the syntax of the language itself. Smalltalk, Python, LISP, and (to some extent) C are very "sparse" languages, in the sense that the designers created very streamlined syntax and added features by defining libraries/classes on top of that simple syntax. FWIW, I see REBOL as lying closer to the "sparse" end of that spectrum than the "rich" end. But the punch-line is this: if I want to write sophisticated text-processing code... ...in this language... ...I have to learn this... Perl regular expression syntax C regular expression functions Python regular expression funcs/objs REBOL PARSE dialect In *ANY CASE* one may need to learn something. If one already knows other Unix/Linux tools, such as grep, AWK, etc. or has a Computing Science background, then the effort of learning RE syntax in Perl is simple. If one already knows BNF from a Computing Science background, then learning the PARSE dialect is relatively straightforward. (For people who have no background that supports either, I suspect that individual thinking/learning styles would *STILL* lead to different people having different experiences. And that's OK. We aren't all alike and we don't have to learn alike.) As for the "years..." part, I don't believe that either. I usually learn a new language in a situation where there's something I want to be able to do and I believe that the new language offers some benefit(s). I usually find that, if my choice of language is a reasonable fit for the task, that I can learn enough of the language to get the job done fairly quickly. If that experience is pleasant enough, I keep expanding my understanding of the language by using it for a progressively wider range of application. All along the way, with each significant language I've ever learned, I find little moments of "enlightment" when something clicks into place and my insight into the language, its world view, and its usage will take a little quantum leap. But don't tell me it takes "years", because I know better. Been there, done that. Many times. Of course, if you try to take a language too far out of its comfort zone, there's no amount of experience that will make the task easy. Don't ask me to be productive while writing an XML parser in COBOL! ;-)
> To use rebol you need only rebol & inspiration. >
That statement has enough truth in it to be severely misleading. I think it's A Good Thing for a language to have a "gentle slope", so that you can quickly learn enough to begin using it. But I flatly reject the notion that this is sufficient for all situations and tasks. Example 1: Have you ever used REBOL to work with XML data? If so, did you write your own XML parser, or did you just (as I did) say something like content-block: parse-xml read %somefile.xml and then proceed with the task of doing something useful with the data in the content block? To parse XML in REBOL, you need only REBOL and inspiration. But you can get on with the job *MUCH* faster if you call on PARSE-XML as a "black box" and use its output, than if you embed in each application a hand-written one-of-a-kind XML parser written with PARSE. Example 2: Have you ever used REBOL to create a graphical user interface? If so, did you create your own interface totally out of View primitives, or did you use the VID? To create graphical user interfaces in REBOL, you need only REBOL and inspiration. But you can get on with the job *MUCH* faster if you can use VID to put together an interface out of standard components, than if you hand-craft a totally inspired and creative approach to human interfaces for each application you write. It's fun to try to create new things. The effort often leads to useful learning as well. It's also true that exploratory programming is a critical part of the process of creating code that ends up being worth sharing and/or re-using. But there's also a legitimate role for getting things done by plugging together existing components that work well enough together, and then moving on to the next task.
> With a highly structured big library we compete > with this languages in their best field: > giving jobs to highly skilled experts instead > of power to users.. >
I must again take exactly the opposite view. If we fail to offer the newcomer to REBOL a large collection of existing code (both for the purpose of study *and* for immediate black-box re-use) then we condemn him to the task of building everything for himself from first principles. Such a task is much more suited to "highly skilled experts" than to everyday users. In fact, there *is* a start on such a collection already; it lives in the email archives, on various volunteers' web sites, in the published books, tutorials, and documentation, and (of course) on the World-Wide Reb. All I am proposing is that some of us, and especially the potential audience of newcomers to REBOL, would see benefit in having this collection pulled together in one place and made simpler to search, access, and use (or re-use). I do *not* suggest that everyone has be required to use it, but I strongly feel that to prohibit its use on the basis of some people's religio-philosophical positions or preferred coding styles would pose an unnecessary limit on the growth and acceptance of REBOL among those who don't have the time, skills, or patience to recreate everything for themselves.
> Suggestion: script-database (oops, me? Yes:) > - global index to »the world«:
<<quoted lines omitted: 22>>
> »i like allans scripts. Give me stuff from him first« > ..?
All of those are interesting ideas (especially from a guy who didn't want lots of server-side stuff! ;-), and most or all of them are compatible with what I was trying to propose for UHURU. I'll be glad to discuss any of them in as much detail as you (or anyone) would like, and would be delighted to see them available to work with UHURU. However, I'll close with two observations: 1) The "core" of UHURU would, IMHO, be far easier to get up and running that the list above, and 2) Adding a reasonable amount of conventions regarding format and documentation would, IMHO, make all of the above more easy and effective.
> and final, remember rebol means lightweight. > If i really need that lot code cpan's/cvs's are meant for, > first i check what i do wrong. > chances are it's a thousand-wheeler.. >
And finally, remember what Sir Isaac Newton said, (here I'm quoting from memory, so please forgive any inaccuracies) If I have seen farther than others, it is because I have stood on the shoulders of giants. If learning and re-using ideas from others was good enough for Sir Isaac, it's certainly good enough for me. If the effort to create an accessible library makes it possible for newcomers to REBOL to stand on the shoulders of coding giants such as Carl, Allan, Petr, Ladislav, yourself (and I'll stop here with apologies for not having time to list everyone I'd like to!), then I'll be quite satisfied with the achievement. -jn- ------------------------------------------------------------ Programming languages: compact, powerful, simple ... Pick any two! joel'dot'neely'at'fedex'dot'com

 [42/44] from: gscottjones:hotmai:l at: 25-May-2001 10:03


From: "Joel Neely"
<snip> > Don't ask me to be productive while writing > an XML parser in COBOL! ;-)
So THAT is what that all day meeting was about! (:
<snip> > If the effort to create an accessible library makes
<<quoted lines omitted: 3>>
> then I'll be quite satisfied with the > achievement.
As usual, Joel, your command of the language is awesome, and your grip on the important issues for the community is firm. I think you are on target with the basic goals of the proposed project. Chris is doing a great job of clarifying, interpolating and syncing all the helpful comments. I guess all that's left for me is to kibitz from the side-line. ;-) Like Volker, I tend to do a lot more cutting and pasting from example code so that I can tweak to do my own thing. But I do think that your ideas, Joel, and the compilation of ideas by and from Chris are on target with the more generally beneficial central repository. In my sleep-deprived ramblings yesterday, I did not intend to imply that the central server(s) needed to be smart, per se. I meant that taking the system as a whole, it would be nice to have control of some of these abilities. Maybe some of what I was suggesting would be better served as suggestions for future REBOL module/package distribution/control methods (REBOL/* 3.*). I just wanted to toss out the ideas, so that those who actually know the backs of their hands from the fronts could chew on the ideas (do lead paint chips and dried frog pills cause mid-life dyslexia?). It sounds like this has been happening. Good! Meanwhile I just need to figure out how to stand on the *ground* before I can worry about standing on the shoulders of giants! ;-) --Scott Jones

 [43/44] from: agem:crosswinds at: 25-May-2001 22:37


>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 25.05.01, 15:04:46, schrieb Joel Neely <[joel--neely--fedex--com]> zum Thema [REBOL] Re: [Fwd: Re: RSL: Rebol Standard Library]:
> Hello, again, Volker, > We simply have different perspectives on what makes a language > learnable and what makes a programmer productive.
Not so much, but you express them better ;-) oh, did i say its very inspirating :)
> -jn- > Volker Nitsch wrote:
<<quoted lines omitted: 16>>
> of the application domain, I have to invest the time to learn > something.
Hm, well i read it sometimes. IIRC carl said something before going productive in smalltalk one has to learn all the collections and how they work together. This compared to similar powerful series.
> That's true whether the "something" is the notation of the > language, the capabilities of built-in language features, or
<<quoted lines omitted: 8>>
> FWIW, I see REBOL as lying closer to the "sparse" end of that > spectrum than the "rich" end.
hm.
> But the punch-line is this: if I want to write sophisticated > text-processing code...
<<quoted lines omitted: 4>>
> REBOL PARSE dialect > In *ANY CASE* one may need to learn something.
parse string [thru »this« copy gimme to »that«] is usefull. »How are the dotsused in RE? Ups.«
> If one already knows other Unix/Linux tools, such as grep, > AWK, etc. or has a Computing Science background, then the
<<quoted lines omitted: 15>>
> expanding my understanding of the language by using it for > a progressively wider range of application.
»perl? Arg? No, never understand! - rebol? Ups, i write a script i use?!« notes on the HP. I try to talk about the first language ;-)
> All along the way, with each significant language I've ever > learned, I find little moments of "enlightment" when something
<<quoted lines omitted: 11>>
> That statement has enough truth in it to be severely > misleading.
Yes, it did that :)
> I think it's A Good Thing for a language to have a "gentle > slope", so that you can quickly learn enough to begin using
<<quoted lines omitted: 29>>
> plugging together existing components that work well enough > together, and then moving on to the next task.
Yes yes yes yes ! 'parse and 'view ! :) i never wanted to talk about language without library. 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, because with SPC you know what you want, with libraries/frameworks you dont. (calling »the programmer« »you:) 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:). Carl has it. I like to find functions quick and tell my stuff with few words. Dialects have no other use than helping that in a way ;-) I think the core-libraries should be build in and carefully balanced against each other, and cover the really important parts. 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. Maybe not bad, but not really rebol..
> > > > With a highly structured big library we compete
<<quoted lines omitted: 9>>
> is much more suited to "highly skilled experts" than to > everyday users.
Want to mention the white-box-reuse. If i look in the library there are some of Carls scripts which have an example-section on the end which one has to outcommend before use. Making this an option would need if not args/no-example[ ... ] and thats the crux with black-box: you have to code much more options, and they bloat the code clarity, where a single char patch would be sufficient. And, having customized a script for use gives a good feeling specially to beginners (its another cake for a kid if it was involved with baking). I think »you can touch it« is a good message for rebol :)
> In fact, there *is* a start on such a collection already; it > lives in the email archives, on various volunteers' web sites,
<<quoted lines omitted: 4>>
> together in one place and made simpler to search, access, and > use (or re-use).
Yes. hm. Maybe more in form of a story? Iam clicking the easy..'s here, small examples which are presenting a lot of ideas. I had read them quick, and after that i suddenly had known how to use vid / draw . That could cover some related scripts with examples and sandbox. Think about an easy-cgi with embedded webserver, some cgi's from the script-lib and an editor where they can be changed. Edit the html, start the browser, »wow! Iam programmer! A, mythical cgi simple gets the »?«part of the url? :)«. Instead of »i know i want something like this« - search? You know, beginners..
> I do *not* suggest that everyone has be required to use it, > but I strongly feel that to prohibit its use on the basis of > some people's religio-philosophical positions or preferred > coding styles would pose an unnecessary limit on the growth > and acceptance of REBOL among those who don't have the time, > skills, or patience to recreate everything for themselves.
Hehehe, lets play rebol-gods :) 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 rebol.com. We pay them for that ;-) IMHO our level should be more to give examples instead of to give solutions. Well, it may even be dangerous to establish second-class solutions while Carl hesitates a bit having the perfect solution somehow in mind«, but then has to stay compatible to lib-apis? ;-)
> > > > Suggestion: script-database (oops, me? Yes:)
<<quoted lines omitted: 34>>
> 1) The "core" of UHURU would, IMHO, be far easier to get up > and running that the list above, and
can't be go friend with automatic hidden install/update to users. Want to have all stuff visible. Having a place to get and collect a current developer-version would be fine. But the embedding in applications should be made by hand. And placed on my disk/server/.. . Ah yes, and the sandbox..
> 2) Adding a reasonable amount of conventions regarding format > and documentation would, IMHO, make all of the above more > easy and effective.
If well done, yes. Btw i would stay heavy on rebol & scriptheader, instead of XML (who mentioned that?). After all, to XML can translate a litte script..
> > > > and final, remember rebol means lightweight.
<<quoted lines omitted: 13>>
> here with apologies for not having time to list everyone I'd > like to!), then I'll be quite satisfied with the achievement.
Even giants Newton and - ahem, was it Gauss? *sigh* had dialect-problems about the right way of integrals-«apis« :) so the right way to say the basics seems to be really a giants job. And a »standard library« needs a lot of giants farth-seeing. I would prefer creating »standard examples« instead of »standard libray«. hm. what will i say with this?! Well - .. Volker

 [44/44] from: agem:crosswinds at: 25-May-2001 22:37


>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 25.05.01, 14:03:56, schrieb Joel Neely <[joel--neely--fedex--com]> zum Thema [REBOL] Re: [Fwd: Re: RSL: Rebol Standard Library]:
> Hi, Volker, > I guess everything I have to say can be summed up in these > statements: > 1) We agree (more than you seem to perceive) with respect > to a smart-client-dumb-server strategy. I can't speak > for anyone other than myself.
Sorry for the sound. Iam not an native english writer and was more thinking than writing, partly trying to confirm me to myself ;-)
> 2) You seem to prefer to develop by cut-past-and-edit. I > prefer to have the option of re-using code units that > package generic functionality. Each of us should be > able to program in his preferred style.
Hm, we agree here to. I try to avoid version-conflicts by copying the script to my project-directory, ignoring updates sometimes, but avoiding hidden code-breaks (i have only to obey core rebol changes). If i apply an update, iam very used to visual diffs, like mgdiff on linux or windiff. Thats a surprising efficient way to see what has changed, and mix my changes with updates. Also rebol is short and says a lot »between the lines«, so it is more efficient to write an »open« script with some places to edit by the user, then to generalize, blackbox and add all the usefull options. You see, in rebol we often answer to »how can i do« with »look at [source send]«, where we otherwise (java, perl) would talk about api-secrets. And this »open« scripts have to be changed by me..
> I do have some more specific responses to point you raised > in your email, but I'll cover them separately to avoid > creating another war-and-peace post. > -jn-
-volker

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