[REBOL] Re: [why-REBOL] Pros and Cons / what's so special
From: greggirwin:mindspring at: 24-Jun-2004 15:22
Hi bry,
This turned out a bit lengthy, but don't take the length of my reply
as an "attack". I like it when people put me on the spot to justify
my views on REBOL; it helps me to see other views; it helps me to take
a step back and think about things in detail. Also, if this is
disjointed, I wrote a bit this morning, then finished while eating
lunch.
>> PARSE (and all that it implies)
bic> I'm curious what do you consider to be an 'implication' of Parse?
The ability to create dialects--whether new and novel, or for parsing
existing data--using a pseudo-BNF description; no lexx, no yacc, can
use either string or block format depending on whether you need
complete control or want to leverage the ability to parse any data
that fits within REBOL's lexical space.
bic> When I think of implication in the context of a programming
bic> language I do not think of implied uses for parts of the
bic> language, but implied ideas about the problem domains to which
bic> the language is applied and implications about the nature of
bic> programming itself.
Yes, REBOL is meant to facilitate the exchange of information. To
understand that information--which will describe many and varied
things--you need to be able to adapt to many problem domains. This
extends one of the basic idioms in Forth development: build up a
vocabulary with which you can describe the solution to the problem.
It's a language creation toolkit. Other languages (Lisp, Forth, Logo,
OCaml, etc.) also let you do this kind of thing, but not in ways that
are as easy as REBOL. This is important because there are going to be
thousands of dialects, so more people need to be able to create them,
not just the .001% who are true language/parsing geeks.
>> protocols
bic> this is something that I think libraries, if included in the
bic> distribution of the language, can give equivalency to rebol's.
bic> that I might have to do an import statement to use that library
bic> doesn't really bother me.
1) How many languages integrate them seamlessly? For example, in
most languages, the syntax to use them is different than for
files, varies between protocol types, and/or requires that you
instantiate a different kind of object after *you* figure out
what the protocol is by analyzing the string that represents
a URL.
I'm not saying they don't exist, but let's list them.
2) You don't mind doing the import, but now you also have to make
sure your users have that module if you deploy the app, correct?
3) The scheme/protocol model in REBOL is open for new protocols to
be added, so you can integrate new, perhaps novel, schemes that
work just like native ones--there is no visible difference.
(Yes, this could use more docs, like other areas...)
>> human friendly syntax
bic> this is a mirage, to do simple things yeah like send
bic> [bry--itnisk--com] 'hi', my mother can use rebol, but even when it
bic> gets to the point of an automated mailing list the human friendly
bic> syntax is not going to be simple enough for her. At that point it
bic> means the human friendly syntax is just another programming
bic> language
Let's not confuse the language's syntax with the problem of complex
application development, those are two separate issues. Human friendly
syntax won't make normal people "real programmers"; Normal people care
only about the end result. We have a number of normal people on the
list who do amazing things with REBOL. No, not everyone will want to,
but REBOL is like BASIC in that it can be used by hobbysists and
people who have a need for simple applications.
Using your example, for the sake of argument, I think a lot of people
*would* be able to do this kind of thing:
mailbox: [
scheme: 'pop
user: 'project1
host: "mail.xxx.org"
smtp: "smtp.yyy.com"
pass: "gregg"
address: [project1--xxx--org]
]
list: [[foo--bar--com][baz--foo--com]]
box: open mailbox
while [not empty? box] [
message: import-email first box
send/only list message/content
remove box
]
bic> , and if that's the case it can be in the way of understanding
bic> for someone who is used to languages in the C family for example.
bic> The lack of true variables etc. all these things can stand in the
bic> way of understanding.
It's a catch-22 because, as long as people think in terms of other
languages, that stands in their way of understanding REBOL. If REBOL
worked like other languages, there wouldn't be any point to it. There
is some validity when people question the need for new languages upon
looking at languages that aren't so very different from what's come
before.
You certainly gain leverage across languages that are similar, hence
the power of REBOL dialects and, for those coming from Lisp, Forth, or
Logo, they get the benefit you cite. That is, someone coming from Logo
could make a lot more sense of REBOL than PHP.
bic> you tell someone who isn't used to Rebol about how understandable
bic> it is, with its human friendly syntax, and then give them some
bic> clever code...
Again, you're comparing apples and oranges. Clever code has nothing to
do with how human friendly REBOL's syntax is. "Human friendly", to me,
means things like:
* The syntax rules are minimal and easy to understand, without
a lot of special cases to remember
* There is as little line-noise as possible
* It doesn't require extreme verbosity or terseness
* It uses words you could guess with a bit of common sense
(e.g. 'append vs 'strcat, <> vs !=)
* Lists start at 1; they aren't numbered 0 to n-1
* It doesn't require you to give it a lot of detail if you
don't think you need to. e.g. for quickie apps, do I need
to declare and specify types for all variables?
bic> Currently I'm learning J, it has a very human unfriendly syntax.
bic> I don't really find that any more of a problem.
Maybe you don't (I haven't looked at it), but could a smart
non-programmer (e.g. we have a couple doctors on this list) grok it
and do productive work with it?
>> reasonable size
bic> do you mean reasonable size in the size of the language
bic> implementation, don't know if that matters for most things...
That's what I meant, and it matters to *me*! It's "perceived value"
though. The original VB runtime was ~265K, big for the time (1991) and
I used the QEVBDBF library (another ~375K) for a commercial app I
built. I didn't mind at all because they provided enormous value to
me. Same for the old QB compiler. It didn't produce the smallest EXEs,
but it was a lot better than using C.
Also, I'm on slow dialup out in the country, so size matters a lot to
me as an end user.
I agree that a lot of people *don't* care about this, but some of that
is ignorance about alternatives. If all you read are mainstream trade
rags, Java and .NET are the norm, so you may not know what could be
done with toolset of, for example, REBOL+PowerBASIC.
bic> Does comes pre-built from the factory have to do with there being
bic> only one implementer? There can be Lisps that come pre-built from
bic> the factory.
Pre-built, meaning there is a compiled version available from a
reference standard source. Anything that avoids the "oh, you need to
build it with *this* option, which our distro doesn't use" issue.
bic> I don't know exactly what you mean by semantic exchange here
It means I can send a message from one place to another, and someone
on the other end can understand its meaning. The big deal here is
that, with REBOL, you can make the same message easily understood by
both people and machines.
bic> I haven't really seen anything built in rebol, other than the
bic> async protocol, that has given me reason to reconsider the usages
bic> I think it most appropriate for. However maybe this is a
bic> difficult thing to do.
Have you seen any of the following:
AltME
IOS
Rugby
Temple
PDF-maker
NREN-Detective (incl. its installer)
ReViewer
Q
RASH
Konka
Oldes' SWF-dialect
Organised
any of Allen, Cyphre, or Oldes' games
Vanilla, Andrew or Volker's Wiki tools, Graham's VIDWiki
Etienne's skin system
Oldes'(?) texture generator
FTPGadget
SlashView
Bo's backup app
The REBOL.org librarian desktop app
Graphic demos from Cyphre, Oldes, or Anton
Advanced algorithm implementations and tools
from Ladislav, Romano, Jan Skibinski, and
others
Advanced UI styles from Cyphre and others
Cyphre's translator
Thanks for listening!
-- Gregg
