[REBOL] Re: [Fwd: Re: RSL: Rebol Standard Library]
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:
> >
> > 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.
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
> 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.
hm.
> 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.
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
> 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.
»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
> 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.
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
> 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.
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
> > 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.
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,
> 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).
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:)
> >
> > - 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
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.
> > 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.
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
