REBOL
Downloads Products Documents Community

REBOL 3 Motivation

By Carl Sassenrath
CTO, REBOL Technologies
Revised: 16-Sep-2010

Contents

History of Development
The Target Market
Primary Objectives
Schedule (Updated)
FAQ
Where can I find out the 3.0 details?
Is REBOL 3.0 open to my feedback and ideas?
How big is the 3.0 team?
Will documentation updates be included?
What about Altissimo?
Will there be an advanced debugger?

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:

LightweightREBOL itself is tiny, and its apps are virtually microscopic. Not only can REBOL be downloaded and installed in less than a minute, but the programs themselves are typically less than the size of a web page and wield substantially more power. In my book, Macromedia Flash is lightweight and .Net is not. Why is this important? Because it means you can easily create and continuously revise your program to the point of near perfection (within its specific domain). Lightweightness enables greater creativity because you can afford to experiment so much more.
DistributedIt runs on the client. It runs on the server. Both are independent, yet both are united by a common language, the semantic cornerstone, REBOL itself. Distributed does not need to mean complex or heavyweight or any of what has become implied by the word in recent years. REBOL was created to solve this problem. What other software technology can so easily be the client, the server, the connection, and the persistence (the storage)?
ApplicationsBy this I mean "doing something useful". Solving a problem. I'm not talking about large do-everything traditional applications. I include and actually prefer the reblet (REBOL applet) model. The little app that does exactly what's needed. And, larger apps (e.g. AltME) are just frameworks that hold many smaller apps.

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:

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).

About | Contact | Support | Privacy | LicenseREBOL Technologies 2013