REBOL 3 Motivation

Contents

History of Development

REBOL is unique. In the early days of REBOL more than a decade ago, the design of the language was unique enough that there were dozens of deep unanswered questions.

For example, how well would the block mechanism really work for the expression of both interpreted data (code) and raw data? Could an entire language be built around the single fundamental concept of a series? Would REBOL's left-to-right expression precedence be more or less useful than the level's-of-precedence models found in most other languages? To what degree would the dialecting concept become a primary principle of the language? What should insert and other such series actions return? How deeply could network transparent messaging be implemented?

There were hundreds of such issues and questions. Back then, I could only make an educated guess based on two decades of language theory, design, and implementation experience. On many questions, I would debate myself for weeks before reaching a conclusion, and even then, I would not know if the final decision was the perfect decision.

The answers to these questions affected not only the overall design of the language, but also the internal implementation. As with any software system (regardless of how well designed) new ideas and deep changes erode the beauty of the original structure. Over time, the implementation becomes brittle and difficult to update and maintain.

Now, after many years of deep, daily experience with REBOL, I think we know the answers to many of these questions. Yes, for the most part, I think a lot was done right. But, for a few parts of REBOL, I think some fundamental improvements are necessary.

For example, I believe that some of the main design principles of REBOL ports were flawed. Second-order features (such as port field auto-inheritance or even the port-as-a-series concept) were placed above first-order features (like easy I/O access methods) and too many variations of external devices were squeezed into a single port definition, resulting in a large bloated port object. Some of these issues also hold true for REBOL's graphical object, the face. The standard face object became too large for implementing applications that might include thousands of graphical objects (such as games or very complex user interfaces).

In other areas, REBOL has simply grown. For instance, many applications have outgrown the original REBOL design principle of programming-in-the-small (PITS). There are some pretty fantastic REBOL applications out there that really show the power of REBOL, but I know for a fact that the PITS model makes them a bit more difficult to build and maintain than they really should be. REBOL needs to add a strong programming-in-the-large model.

In conclusion, it is time for REBOL to grow and mature. Note that I'm not talking about making REBOL larger and heavyweight. We don't want a 10 MB download or complicated install process. That's not what REBOL is about. REBOL is about being lightweight and agile, and REBOL 3.0 will remain that way. It's time to make REBOL what it truly can be. What you and I both want it to be. And, this time, you can help.

The Target Market

You've got to have a target. You must provide that singular special purpose that makes you the perfect fit for a specific group of people.

Being "general" and able to "do everything" at first seems like a good thing; it's a Swiss Army knife. Yes, it is very difficult to set aside what seems like a huge strength and say "we don't want to do everything" or even, "REBOL is not for everyone".

However, I've built an "everything" product before. The Amiga Computer (technology years ahead of other personal computers) suffered from the "it's an amazingly general purpose computer" syndrome. It was so good in so many ways that we all felt Amiga should do everything for everybody. But, that's not what people buy. People buy solutions. People buy applications. Very few of us buy great technology just to own great technology. (And, I mean "buy" as in "accept and use", not just as in "pay for").

Those of us that went through the Amiga unfocused marketing experience suffered from the "do all end all" attitude. Just ask any Amiga user; they will display their painful scars. And, I can attest those scars will never vanish.

Eventually, the world, not Commodore, defined what the Amiga was. In the USA, the Amiga became known mainly as a low-cost video editing system -- defined by the NewTek Video Toaster. Outside the USA, Amiga was an amazing game/hacker machine with tens of thousands of games and related titles.

So, I've been-there done-that (the "do everything" approach), and I do not want to take that road again. It's time to define REBOL's target, and I think most of us understand now what that target should be. REBOL is perfect for lightweight distributed applications. Yes, that's our revolution, and most likely, that's why you use REBOL and why you've even taken the time to read this far.

Yes, I know... Those words sound a lot like marketing buzzwords. I don't like buzzwords either, so let's not be blurry here. Let's have a sharp focus. Here's what I mean:

Yes, I know, this target market is not new. I've said it before. I've also seen the puzzled faces that don't quite get it. But, I'm used to that. There were just as many puzzled faces in 1983 when I brought multitasking to personal computers. I would say "it's going to have multitasking" and people did not get it. "What's it good for?" they would ask.

I think we're at that critical time in history, the edge of the next wave. With improvements in web browser methods (things like AJAX), I think everyone is starting to finally "get it". The race is on. They see our dream of what it means to be a distributed computing platform, and they know it's the golden ring.

So, it has come time for us to shift into high gear. It's time to unite our community, power up the REBOL 3.0 laser, and burn a hole in those weaker approaches. It's time to lead the way. The REBOL way. Vive la REBOLution!

Primary Objectives

REBOL 3.0 is a huge project. However, it's a focused project. We're not going to try to build-in every single possible feature nor solve every developer problem or desire. Instead, we are going to make REBOL a more robust and powerful system, and let members of the community focus on building specialized plug-in features that are specific to their needs.

Here is a brief list of the primary objectives behind the REBOL 3.0 design:

• Continued Lightweightness
  We flat out refuse to bloat REBOL. Yes, we will be adding many important features to 3.0, but we're also chopping some things out. The footprint will still fall under 1 MB, but with more power than ever before.
• Programming-in-the-large
  More powerful apps must be easier to build. That means adding modules (namespaces and scoping control), multi-tasking, more-efficient GC, and more debugging "hooks and tools".
• Hybrid Open Model, Open Interfaces
  Improvements to REBOL need to happen faster and be more widely supported. In order to do that, we are redesigning the REBOL kernel to allow a greater degree of open interfaces, both internal (built-in) and external (plug-ins). This includes a new model for external ports (e.g. MySQL port interface to name just one), media loaders/savers (e.g. JPEG saver), and generalized plugin modules (e.g. OpenGL).
• REBOL-in-the-Browser
  It is a simple fact that for many users, if you're not in the browser, you're not in the game. So, this feature is a must-have, and we will be providing the necessary source code (as an open interface) to get your help and make REBOL work across all browsers on all operating systems.
• REBOL/Services Built-In
  All variations of REBOL will be able to securely connect to other REBOL nodes and services and efficiently exchange information. Creating such network services must be truly lightweight, both in construction and execution.
• Optimized Graphics
  We're gutting the existing graphics subsystem and replacing it with a better, faster, and more efficient design. On top of this, we (and we hope a lot of the community) will layer a standard GUI framework that is both more functional and easier-to-use.
• Greater Locality Support
  It's time for REBOL to do a better job at supporting native languages and character-sets. Our goal to expand support with locality and unicode enhancements. In addition, it is a goal to release 3.0 with French, Italian, and perhaps one/two other languages as part of the standard distribution.
• Resident Storage Method
  REBOL's flat text file storage method has served us amazingly well. Applications like AltME store and access 10's of thousands of REBOL-formatted records that way. But, the time has come to provide a better built-in method for such data.

A variety of other features will be part of 3.0 (e.g. Rebcode), but we do not list them separately here. Details to come later.

Schedule (Updated)

REBOL 3.0 is a very large software project, and we all know how those go. We distributed alpha test releases beginning in June 2007, and the first public alpha in Jan 2008.

But, there's a lot more to do, such as the Unicode conversions.

I think the degree to which we can make this schedule happen depends to a large part on the REBOL community itself. Unlike prior releases, we don't plan to do everything ourselves. We need your help. We will be setting up a web page to post "requests" for what we need.

I should also mention that release timing takes priority over our feature set. If we need to yank a few non-critical features in order to get the release out sooner, we are prepared to do that. We can always add back missing features in later releases.

FAQ

Where can I find out the 3.0 details?

We will make details more clear as development proceeds, and we have something available for you to download and test.

Is REBOL 3.0 open to my feedback and ideas?

Absolutely. We need your help and ideas. But, you're going to need to push and prove them. If you absolutely want to see a specific feature in 3.0, you need to be willing to do a lot of the work - both the research and the development. Don't just say "please support MySQL N.0"; instead ask "how do I add support for MySQL N.0".

How big is the 3.0 team?

The team currently consists of five people. We will be adding a few more. Specifically, we will need expert C coders with specific OS experience in Win32, OSX, Linux, BSD, and others.

Will documentation updates be included?

I think it is critical to refresh and revise REBOL's documentation for 3.0. More specifically, I want new developers to be successful with creating REBOL applications in the shortest timeframe possible. There is a lot of doc work to do here, and I must admit that I do not know how it will be accomplished. I think we need someone with this skill to step forward and lead the way.

What about Altissimo?

Some of you know about my enthusiasm for the Altissimo project from the 2005 REBOL Developer's conference in Italy. Altissimo is intended to be a great framework for lightweight applications. That has not changed. But, it was in fact Altissimo that pushed us to do REBOL 3.0. We did not want to establish massive adoption (millions of users) without providing a more powerful REBOL first.

Will there be an advanced debugger?

The REBOL 3.0 kernel will include new hooks for obtaining debugging information. For example, you will be able to obtain a backtrace of functions, step through sections of code, set a breakpoint and examine local varaibles, and more. However, we do not plan to be providing an IDE at this time. (We want one, and we plan to build or partner with someone to build a REBOL-based IDE in the future).