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

[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: "" smtp: "" 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 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