What's Wrong With REBOL?

[GedB]

I'm not trolling here, this is a geniune question.

You must have noticed by now that Rebol hasn't set the world on fire.

Why not?  What is wrong with Rebol?

Most importantly, what needs to change so that the Rebolution can begin?

[Gregg]

(The following are just *my* opinions, naturally)

1. It's not Open Source. I'm not advocating that it *should* be, just that there seem to be two popular camps for languages these days: those from large companies and those that are Open Source. If the first case, you get corporate buy-in, in the latter, you get the alpha-geeks--both are important.

2. It's not from a big company with deep pockets who can force it down people's throats.

3. It's different. People who take the time to understand it--and not that much time is required--see the benefits, but you need to have an open mind.

4. It's ahead of its time. We aren't yet using REBOL, in deep ways, for what I see as its intended purpose--messaging--which is where it will really shine. Even as others try to tack it on, it won't be the same.

5. No IDE. People kind of expect them for non-geek tools. I don't think an IDE, as we think of them today, would really help people all that much, not until we have more tools for development-in-the-large with REBOL. Good REBOL IDEs will be very different than the 90's model all of them are built on today (IMHO), and there will be more than one. Like dialects, you won't have a "REBOL" IDE, but more domain-specific tools.

6. No O'Reilly book on it.

[Gregg]

I don't know if there's a silver bullet that will change things. I don't care if REBOL takes over the world--though I think the world would be a better place if it did. :-) For me, it just has to do well enough that RT will keep it alive and benefit from it themselves.

For our part, we need to start creating some commercial successes with REBOL, to help RT.

[-jn-]

Here are a few issues I believe to be relevant:

0) Familiarity: REBOL syntax (such as it has ;-) and semantics are significantly different from mainstream languages, meaning that at first glance a newcomer is likely to feel the language very foreign to her/his normal way of thinking about programming.  That's enough to stop some people in their tracks.

1) Transparency: REBOL functionality occurs in "big bangs"; the community (much less the world at large) doesn't know where the product is headed, what features may be under development, etc. until the release is done. One of the major attractions of open source tools IMHO is that the community of users feel themselves to be participants (at least potentially) in the process of establishing priorities, agendas, etc. (whether or not they actually avail themselves of the opportunity). Successful products (whether open source or not) often cultivate a very open relationship with their users.

2) Maturity: REBOL as a *product* is not yet there; until the documentation, infrastructure (bug reports and tracking, community resources, mailing list and archive) are stable, the world at large will be less likely to want to get involved. As long as there is no authoritative source for *all* programmer-relevant information about a language, it will have trouble building to critical mass.

3) ROI: Every highly successful language has a clear (to outsiders!) answer (or more than clear one answer) to the question "What benefits will I gain from investing my time and energy in learning this language?" The answers may involve such issues as performance, availability of job opportunities, interesting open-source projects, special features providing high leverage in some specific problem domain(s), wide range of published reference materials, ease of learning, support, portability... and so on.  Sometimes the question is even more pointed; "What can I do with this new language that I can't already do, and why would I need/want to do that?" Programmers won't spend time and effort learning a skill that they don't perceive to have sufficient payoff.

[Edoc]

Disclaimer: I love REBOL like a brother, so don't take these comments as bashing or trolling.

One could probably write a case study as to why REBOL has not caught on. I've thought about writing it up on a weblog, but it might be picked up by search engines and I much prefer to promote REBOL.

Lots of reasons, in no particular order:

<begin list:>

It's just damn hard to get people to use a new language under the best of circumstances. Major barrier for any technology.

REBOL has few people writing about it-- on the web, that is. Therefore few know about it. Only a handful of websites out there for REBOL, and none of them really active and plugged into the blogging/RSS world like python or the other languages.

The chicken-and-egg problem. Many programmers won't touch a language that few others are using. As popular as Python and Ruby are, even they have to wrestle with this issue.

It's not a curly-brace language (not fully OOP, etc.) Most programmers consider this a bad thing.

You can't expect to combine features of 2 or more relatively unpopular languages, Forth/postscript and Scheme/Logo and emerge with a popular one.

REBOL is not a compelling value proposition for the commercial (Windows) market, clearly not well adapted for the Mac, and not free & open source for the remaining platforms of the world.

REBOL is not super-FAST. Blame programmer mindset for that one. They would write in Klingon if it were as fast as C. Programmers are almost always fixated on raw speed and memory economy, 2 things which most language implementors keep believing will not matter in a few years.

REBOL is tiny. Wha?-- how is this an issue? Well, it's hard to explain, but most folks associate anything <i>this</i> tiny with a lightweight toy and not a robust, scalable language. Given the choice between a 5MB download and a 500KB download, most programmers will believe they're getting more for their investment with the 5MB download. Crazy, I know. Microbloat learned this marketing lesson long ago.

REBOL wants to be its own (proprietary) platform in an era when proprietary platforms are on the way out. MS has basically ruined the commercial/proprietary market, such that no-one will let another vendor emerge with a product with any lock-in (real or apparent). Ironic, because that only kills MS's competition, leaving a scorched earth between MS and open source.

REBOL doesn't have strong support for [insert your favorite buzzword]. Buzzword technologies are the one reason someone is likely to consider using a non-standard tool like REBOL. Many possible reasons: RT prefers to fully control it's own destiny -- e.g., no support for established proprietary technologies (.zip, PGP, Pdf, etc.), Keeping REBOL small & platform independent is more important to RT than chasing potential fads, etc.

REBOL gives the appearance of a tool that binds the language to its own data format to its closed network layer, whereas most other languages are totally decoupled and therefore "hot swappable" to any open format and protocol. Hmmm, maybe this belongs in the  proprietary solution point listed above.

REBOL appears to some as a "cult" language. Forth, Postscript, Lisp, Unix, Pick and other languages/techs have a fervent following based on adherece to particular mindset or philosophy. In many of these communities, there is a leader or an inner-circle, etc. While I see parallels, I don't agree; nonetheless there are some who perceive it as an Amiga hero-worshipping thing.

REBOL encourages simplicity, partly by encouraging you to avoid complexity. But the real world is inherently complex, and most programmers want a language that scales to handle complexity very well. Simplicity is very subjective. When they hear "leave what you know behind", "you need to think differently" or "don't do it that way, do it the REBOL way", that's when they start to get cold feet.

Most programmers & users prefer Web apps. And other languages are much better established for doing CGI work.

RT doesn't really "compete." It appears to me as though REBOL is positioned as a nice language that you can casually add to your toolkit. That's not nearly good enough for a proprietary language. REBOL probably can't be commercially successful as one of many utilities that a programmer uses on occasion. There are so many good, totally free, open languages out there, and programmers will only learn & use maybe 2 or 3 of them (C++, Java,  C#, Perl, PHP, Python, Ruby). That means that RT, with limited resources & heavy cost of core principles needs to unseat one of these. To do that, you really gotta compete for those programmers and identify capability/features that will enable entry in new niches.

</end list>

People have odd tastes. Any one of the above is enough to "tip" the balance away from REBOL uptake.

What can be done to help REBOL?

Well, first off, a good number of the above items cannot be addressed without REBOL changing certain core values. Ain't gonna happen, nor should it. But the perception thing could certainly be improved.

I think the first thing that any avid REBOLer should do to promote REBOL is write about it (objectivity would be nice) in a weblog.  Go to blogspot.com or what-have-you.com and pick up a free blogging account. Anything that will generate RSS feeds and hopefully gets us plugged into the mainstream channels. Every few days write 4 sentences about how you now perform xyz in 4 lines instead of 9 lines of Python. Be mindful that most programmers don't want a one-liner to send an email in one line, they want to manage and send 10,000 emails with attachments from a database.

Cheers
 

[GedB]

I agree that what Rebol really needs is to be open source if it is to survive.

I don't think the argument that keeping it closed source will compromise compatability across platforms.  Perl, Ruby and Python are open source and they have managed it.

Edoc, I think your exactly right.  Only open source platforms now stand any chance against the might of Sun and Microsoft.

For me, now, I look at Rebol and I cannot say for sure if it will still be around in 5 years time.  Being propietry if RT goes under Rebol disappears.  At least if it were open source I would know that the community is strong enough to keep it going for at least a couple of decades.

[johnatemps]

1 - If you really try Rebol, you love it. A few thinks might be best, but it's a revelation.
2 - Communicate about Rebol with easy thinks it's not always good idea. Advanced developers want démo and doc for advanced features. The one-lines are great, but not serious. Big projects might be shown too.
3 - Open source : not? But RT accept help, and doc can be done with the community. The community concept can apply here.
My 2 cents.

[Graham]

Gedb, I wouldn't worry too much about  the source if RT disappear.  RT have the source code in an escrow account to be released to their major users in the event of their company closing down.

[GedB]

Graham,

That is reassuring to know.

[GedB]

One serious problem I have with the REBOL syntax is the way refinements work.

The refinement appears next to the command, but the values associated with that refinment appear after the other paramaters.

Using RebDB really highlights it for me.  Take the where refinement as an example

Code:

db-select/where * my-table [id = 1]

There is no easy way to associate the [id = 1] with the /where refinement, other than knowing the command really well.

I think something like the following would be so much easier to read:

Code:

db-select * my-table /where [id = 1]

[Edoc]

Ged,
Sounds like a dialect could address those issues for RebDB. I bet SQL would be fairly simple to implement as a dialect.

As for other functions (sort/skip/compare comes to mind), I'm not sure that anything be done.  Here's another recent example of code that probably scares newbies (my apologies to Bo), aka "the freight train expression":

days: head remove back tail insert head copy system/locale/days last system/locale/days

(taken from HTML Calendar)

WRT to the earlier point about REBOL being around in 5 years, I am sure REBOL it will. I doubt Carl would ever put his life's work in jeopardy. REBOL's design shows all of the traits for long-term survival (platform independence, compactness, etc.). On the other hand, REBOL does not seem poised to rise to the top of the "food chain", and that presents a different set of challenges.
 

[GedB]

I get the impression that the basic REBOL language is really just an assembly type language and is supposed to be built upon for other tasks.

So, for example, a dialect could be developed for manipulating lists so avoid the freight trains expressions you give.

Libraries like RebDB could provide SQL as a dialect.

Yet there seems to be a reluctance to create dialects.

I think there might be some good reasons for this:

1) Performance.  What is the performance penalty for parsing a dialect compared to a native REBOL calls?

2) No keyword help for dialects.  I notice this especially when working with view.  With REBOL functions I get to call Help for anything.  For RebDB I can type help db-select and I get a good help message.  In dialects like view I cannot get this keyword help.  This makes it easier to work with REBOL functions than dialects.

3) Developing parses is risky because infinite recursive loops are all to easy to create and difficult to find.

I think that these problems could be resolved with the following:

1) Make it possible to 'compile' dialects to improve performance.

2) Provide a standard means of creating dialects complete with keyword help, etc.

3) Make the parsing functionality safer and easier to debug.

[Ashley]

Yet there seems to be a reluctance to create dialects.

I think there might be some good reasons for this:

That about sums up my view. I'll elaborate on your points by saying that:
1) The process of writing function(s) implicitly does a large part of what a dialect has to do (ie. breaks a "command" up into discrete [argument] components, in a definable sequence).
2) Using the RebDB predicate as an example, a dialect might have us write

Code:

col1 = val1 and col2 = val2

which then probably gets verified and expressed as

Code:

[all [col1 = val1 col2 = val2]]

As a dialect author you probably want to check the validity of this statement before trying to evaluate it, but as a function author you just let REBOL do the work for you.
3) Again using RebDB as an example, a large amount of code can be written to correctly parse

Code:

select * from table where col1 = val1 and col2 = val2 order by col1

as

Code:

db-select/where/order * table [all [col1 = val1 col2 = val2]] col1

but have we really made the task of entering a valid statement any easier? Those familiar with SQL may say yes, while those familiar with REBOL may say no.

[GedB]

3) Again using RebDB as an example, a large amount of code can be written to correctly parse

Code:

select * from table where col1 = val1 and col2 = val2 order by col1

as

Code:

 
db-select/where/order * table [all [col1 = val1 col2 = val2]] col1

but have we really made the task of entering a valid statement any easier? Those familiar with SQL may say yes, while those familiar with REBOL may say no.

Good point, but it strikes me that

Code:

db-select * table /where [all[col1=val1 col2 = val2]] /order col1

Is the best of both worlds.  Would it really be so difficult to change the Rebol/Core to allow it?

[Ashley]

How about

Code:

db: function [block][spec args][
   args: copy []
   spec: join "db-" first block
   foreach word next block [
       either refinement? word [
           insert tail spec join "/" word
       ][
           insert/only tail args word
       ]  
   ]
   insert tail spec join " " mold/only args
   do spec
]

Used as

Code:

db [select * table /where [col = val] /order col /desc]

Requires a block, the only way to pass a variable number of arguments, but doesn't require a REBOL/Core change.