The value of coding a real R3 reblet

Prior to the early 1980's, if you developed a new computer system, you would build the hardware, then work to get the software running on that hardware. Often, there were serious mismatches. The HW developers didn't know what the SW developers really needed.

About that same time, a new theory arose: software directed hardware design. It boiled down to: build the hardware based on the requirements of the software.

This theory applies not only to hardware, but to all abstract layers that should efficiently support the functions above them. And, as you would expect, this theory holds true for REBOL system development itself.

I've been saying for several months that R3 needs not only test suites, but one or more initial reblets -- just to prove out the design. Such reblets do more than prove reliability, they help us to spot missing functions or features. This is even true in the higher levels, such a the GUI framework itself.

Of course, also, one of the nice things about REBOL is that its lean design allows us to make such changes and adjustments normally in just a few seconds, not a few hours. That's the advantage of being lean.

With that in mind, one of the first reblets we're writing is a little threaded BBS client for developers. Initially, my goal was to pick DevBase (source access system) for this stress test, but it's a bit too sophisticated. A few more GUI components would be required.

Anyway, I can hear some of you grumbling already, "don't mess with a reblet, just release 3.0!" Sure, I could do that, but what good is it if you can't run anything useful? Doing that just generates additional noise to our discussions, and additional bug/wish tickets to resolve.

And with a running reblet, even a simple one, you can know that at least one reblet will work. And, that means there's a good chance that other reblets will work too.

Anyway, the R3 alpha along with it's initial reblet will be released sometime very soon. With luck, within the next few hours.

1 Comments