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

[REBOL] Re: [Fwd: Re: RSL: Rebol Standard Library]

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... 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«: > 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« > ..? >
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