[REBOL] Re: [Ping Carl] Re: Need help for justification of using REBOL as devlan
From: joel::neely::fedex::com at: 12-Apr-2001 8:27
I've enjoyed lurking through this thread. Many good ideas have been raised.
In attempting to justify REBOL in a specific environment, I suggest that it
would also be good to address head-on some of the likely objections that
could be raised (depending on the audience):
1) Nobody else here knows it. Why should we commit to a language that
makes you the critical resource both to initial release and ongoing
maintenance of the project?
2) If we use LanguageX, we can buy software components, hire off-the-
street temporary resources, ...etc... to speed up the schedule.
3) What's wrong with all of the other development tools we spent all that
money on last year? How come you technical guys always think the next
editor, language, or O/S is the silver bullet that's going to solve
all my problems?
4) Is that a Microsoft product?
>From other programmers:
1) But I know/like/prefer/love LanguageX! I already know how to build
this system in LanguageX!
2) I already have a bunch of components/subroutines/objects written in
LanguageX. Can we compile your part of the code and link in all of
these other pieces? If not, we'll have to throw them away and
rewrite them! We don't need to waste all of that extra time!
3) But LanguageX is faster!
4) Anything you can do, I can do in X, X++, or VisualX, so why do we
need anything else?
>From end users:
1) I don't want to install anything else on my PC. All those plug-ins
give me the hives.
2) Is it done yet?
3) Which key is the "any key"?
CRS - Psy Sel/SPO, COUSSEMENT Christophe, CPN
I'm not Carl (and I don't play one on the 'net ;-), but I have a very
strong feeling about the following question.
> Could I have your estimation of the ratio Instruction/Statement
> of REBOL ?
I don't think this question HAS an answer, even in principle, for two
The minor one is that the concept of "statement" doesn't even exist in
REBOL; one only writes expressions that are evaluated. Different people
with different thinking/presentation/programming styles will produce
expressions with radically different levels of complexity and radically
different ratios for work-performed-per-line-of-code (or whatever other
meaningless source code attribute may be the current fad where you work).
The major one is based on the fact that REBOL fits into the class of
. It is possible (even desirable) to define new
words that are relevant to the task at hand, to define new generic words
(e.g., 'map , 'case , 'pif , etc. from previous discussions on this list),
and to use all of those words to define still more new words, and so on...
The consequence of this approach to programming is that the ratio of
work (e.g. machine instructions) to SINGLE WORDS in the source code
HAS NO a priori UPPER LIMIT. The more one uses this "pyramid-shaped"
approach to programming, the more work each single token in the source
code can do.
This is a "good-news-bad-news" situation:
Good News Bad News
Compact programs can get lots of Bugs in early/lower definitions can
work done. be very hard to track down, especially
in a multi-programmer team where not
The source code can begin to look everyone knows all of the source code.
like a language tailored for the
application at hand (because it is!) Many languages don't have any such
concept, therefore many programmers
Once a "critical mass" of code is in have to be trained to understand it
place (especially the application- before they can use it well/properly.
specific parts) development can move
very rapidly (as can maintenance). Adding new members to the effort takes
time for them to learn both the base
If the underlying words are well- language and the custom extensions.
designed, they become an extremely
valuable asset for building new If the extensions are poorly designed,
(related) applications. they are not only un-re-usable, but
they can also make the original system
very brittle and fragile.
This benefit doesn't really "kick in" unless/until there is a sufficiently
mature inventory of new words, and unless/until the task is sufficiently
large to justify/utilize this pyramid-shaped
This entire little essay has a good-news-bad-news punchline:
(bad news first ;-)
These are not simple issues, either to work through or to communicate
(especially to a non-technical, e.g., management, audience). I only raise
them on this list because of my respect and high regard for the knowledge
and expertise of the members of this list.
If you put in the hard work (technical, psychological, presentational, and
relational) that will be required to address them, I sincerely believe that
it will greatly improve your chances of selling REBOL. At the very least,
it can enhance your credibility with the audience, and you may live to
fight the good fight another day.
> Some people here should try to impose VB as scripting language .
> I think this would provide a fairly good measure of REBOL's
> code efficiency...
That fact alone suggests to me that they wouldn't be impressed by any
arguments relating to cross-platform portability. [Sigh, grumble...]
Let me suggest that you take some samples of VB code (from a book or web
site if necessary, but samples of actual code from your local environment
would be better), and show how the same things could be done (better ;-)
in REBOL. Bear in mind the different meanings of "better". Faster,
smaller, clearer, more reusable, more robust... you know the list.
... and/or ...
Take some things that REBOL does well, and show how much effort/pain it
would take to write them in VB. I won't try to compose at the keyboard
here, but lots of half-page-or-less examples come to mind:
* A script to take all of the *.html, *.css, *.gif, and *.jpg files in
a directory (but ONLY those files) and ftp them to another box (e.g.
your web server), then send an email telling when the push was done,
how many files were sent, and whether any errors occurred.
* A script to grab a web page, parse the html for <img...> tags, and
copy all the referenced image files to a local directory.
* A useful task driven by an XML spec file, which is read and parsed
to control the activity (for example, the first task above, where
the list of directories and file types per directory is specified
in the XML document).
... and so on ...
; Joel Neely [joel--neely--fedex--com] 901-263-4460 38017/HKA/9677
REBOL  foreach [order string] sort/skip reduce [ true "!"
false head reverse "rekcah" none "REBOL " prin "Just " "another "
] 2 [prin string] print ""