From DocBase

I run the blog at http://hostilefork.com - which was started with the agenda of being proactive in promoting cooperation among software efforts. (Basically to identify the reasons why people aren't working together, and hopefully to make those reasons go away.) I am hostilefork on Twitter

I've used Rebol only a little, at least relative to time I've clocked with other systems. But I have experimented enough to know that it is built on concepts that I consider of foundational importance if I am going to use an interpreted language. These features are not only missing from most popular ones (Python, Ruby, JavaScript), but they cannot be added after-the-fact. One critical aspect is that Rebol can reflect its source code very easily, establishing a duality of code and data which is similar to LISP... but much more nuanced.

Yet Rebol is not being used by very many people. So I'm trying to do what intervention I can to give the ideas more traction. One of the big issues is bridging to the open source community, and as of 12-Dec-2012, the release of Rebol 3's source code under an Apache 2.0 license has made a crucial step in that direction.

Contents 1 My Blogging about Rebol 2 Ideas on this Wiki 3 Some Rebol Projects 4 Notes 5 To Do

My Blogging about Rebol

Though I prefer collaboratively edited sites for institutional knowledge (I essentially wrote the StackOverflow tag wiki for Rebol), I've blogged a bit as well:

• I've written about how the language is built on the notion of a flexible series
• There are some major quirks in the language, but you can perhaps best get to understanding its novelty if you face them very early
• Here are my thoughts on whether Rebol can truly be called a revolution
• I agree with Rebol's head programmer Carl Sassenrath that we need to be careful in using abstractions not meant for human readers

Ideas on this Wiki

• I've contributed ideas for a new REBOL logo
• I started an article where Dialect Design Considerations can be surveyed
• I started an article to help explain the foundations of Scoping in Rebol (more introductory than Bindology)
• A description of Rebol's rationale for not including a substring operation
• I'm trying to motivate people to collaborate on an Interactive tutorial script, in the spirit of Try Ruby!
• I have encouraged a greater engagement and more positive perspective on open source development as part of "Version 3: It's Rebol. Rebooted."
• I'm trying to nail down what some of The Invariants of Rebol are
• Due to dissatisfaction with the user experience of the tag! type, I'm pushing for an Extended tag proposal, which has been evolving as my understanding of the motivations of tag has evolved. The result has grown into a document explaining the motivations of the current implementation of tag!

Taking cues from Wikipedia, I generally feel article pages should try and contain consensus and factual information. The talk pages are where personal opinions are expressed and comments are signed by their respective authors.

Some Rebol Projects

• Even though there's no enumerated type built in, I was able to add one, and I even gave it some interesting features...
• Check out my spec for an Arecibo-Message inspired character encoding
• I've started an initiative to show Ruby programmers how Rebol programmers already enjoy many of the kinds of freedoms they have, called RUBOL
• I created a Rebol dialect called Rebmu which is tailored to trying to let Rebol participate in code competitions based on trying to solve a problem in the fewest number of source characters

Notes

Though it looks odd at first, Rebol code has a lot of consistency to it. Languages like JavaScript and CSS are fundamentally incompatible at a parsing level; they are not based on a shared idea. It's so bad that they don't even support the same comments, e.g. you can use /* */ in both, but // isn't supported by CSS. The desire to allow "a-b" to represent subtraction instead of requiring spaces as "a - b" led to a massive reduction in available symbol space, which sometimes forces the usage of strings in object keys when they're not otherwise required (e.g. "background-color"). That they couldn't standardize something as simple as that shows how little value is put on consistency, to say nothing of the deeper issues.

By contrast, XML set out to build a universal structure. Even XML schema definitions are themselves XML (a step up from HTML, whose specification had a lot of @ signs and not much in the way of <angleybrackets>). Yet although you could encode your CSS or JavaScript code as an XML structure, you sure wouldn't want to edit it that way!! JSON's success is based on XML being too clunky, and as the inspiration for JSON...Rebol would have done it markedly better.

Rebol's source notation brings to the table a lot of the universality that XML should have delivered—but didn't in practice. Yet it is light and minimalist enough in its notation to use for programming languages or stylesheets. There's not a lot of unnecessary symbols, and all the key datatypes are built in atomically to the system.

To Do

• This argument on Lambda the Ultimate about the arity of functions is sound, and seems like a good thing to be addressed somewhere.