Comments on: Understanding the design flow of REBOL 3.0

Comments on: Understanding the design flow of REBOL 3.0

This posting is a bit geeky, but worth understanding. I use a "parallel pipeline with feedback" approach for dealing with design considerations.

I've designed software systems for three decades now for a wide range of companies. Complex software systems have requirement specifications that are difficult to manage (mainly because they change along the way). Because of that, most projects fail, and you never hear about them again. Or, they fail in another way: they don't provide enough of what the end users require.

I've found that a great design requires great flexibility to new knowledge that is gained (or otherwise observed) later in the implementation process. It's a feedback loop (with gain that we all hope is less than unity, for those of you who speak engineerese).

This is, for example, one of the reasons why the Amiga was a great computer. We designed both the hardware and software at the same time. Each affected the other. We didn't get the hardware dumped in our lap then get asked to put software on it. (Which is, unfortunately, all too common in the field of design.)

Recognize that while design and implementation of REBOL 3.0 are happening, you will see me post issues and questions for your comments (mostly on the REBOL 3.0 blog). Often, these are posted well ahead of time to allow enough time for a full discussion prior to a decision and implementation. This also allows a lot of issues that are actually non-issues to cancel-out before the more costly and time consuming stages of implementation (i.e. C code).

Think of it like letting wine age in the barrel before you bottle it. There's a lot of complex chemistry going on.

16 Comments

Comments:

Pierre Johnson
10-Sep-2006 3:36 A blog only allows us outsiders to comment and to suggest only upon topics that you choose.
The blog does not provide us outsiders an open forum to initiate new topics, which could vastly improve REBOL.
Here's one:
value? is a major source of confusion.
current confusing functioning
>> value? a == true >> type? a == integer! >> value? b ** Script Error: b has no value ** Near: value? b

Currently, value? is nearly useless and type? unexpectedly returns "what's behind" a and not that a itself defines a functional.
Out of the box, this purposeful design of REBOL is a major source of confusion for anyone stepping up to REBOL for the first time.

superior "how it should work" functioning
>> ; run-time fix of design logic flaw in REBOL >> >> defined?: :value? >> value?: :type? >> >> value? a == integer! >> defined? a == true >> defined? b ** Error: b has no definitional ** Near: defined? b >> value? b ** Error: REBOL cannot evaluate undefined b ** Near: value? b

value? should return what type? returns and defined? should return what value? currently returns.
Why is this superior? It's consistent. The new value? asks "to what type does REBOL evaluate the definitional (functional) behind a?"
And now see how completely consistent when blocking REBOL from evaluating a:
>> value? [a] == block!

When exploring further, we come into further design confusion. This time, should REBOL return "what's behind" a or return to us intel that suggests a labels a functional?
>> value? first [a] == word!

And since we know b does not label any definitional, inherent design flaws of REBOL reveal themselves when testing against b, which we know does not label (point) to a definitional (functional):
more REBOL quirkiness
>> defined? b ** Script Error: b has no value ** Near: defined? b >> value? b ** Script Error: b has no value ** Near: value? b >> value? first [b] == word!

Why isn't REBOL reporting that b is a lit-word! instead of word!?
A blog is a weak tool for allowing proper vetting and design pipeline feedback.
Ladislav Mecir
11-Sep-2006 5:26:32 Due to the backward compatibility requirements, some of the above proposals are hard to accept, but if we want to remain backwards compatible, it does make sense to change the spec of the VALUE? function as follows:
[ "Returns TRUE if the word has been set." word [any-word!] ]
Pierre Johnson
11-Sep-2006 13:37:28 Has anyone asked, "Why should REBOL be backwardly compatible?"
After all, the REBOL run-time is what about 645Kb? That's a tiny program.
Any scripts/programs built on REBOL 2.0 can run in their own process.
It would be one thing is REBOL was some clunky gazillion megabyte program that required all RAM of a PC to run. The days of 640Kb RAM main memory limit are long gone. There's no expanded memory anymore -- no extended memory either.
There's simply no justification for designing software to be "backward compatible". It's not a file format issue either.
Designing better products demands that excison of legacy cancers -- design flaws and errors.
As an aside, the purpose of my original post is to reveal the lack of way for persons to make new suggestion to improve/fix REBOL ... in light of the weak confines of a blog.
Brian Hawley
11-Sep-2006 17:16:10 Has anyone asked, "Why should REBOL be backwardly compatible?"
Actually, some have asked this question. It has been a recurring theme in the debate over REBOL 3. Personally, I am in the break-if-necessary camp, as long as the changes can be justified and aren't just change for the sake of being different. It's not like REBOL 2 will magically stop working when REBOL 3 comes out.
Maxim Olivier-Adlhoch
11-Sep-2006 23:34:26 AFAICT, with all suggested changes so far, none of my 8 years of REBOL work is compatible with R3 out of the box...
Exactly 0%
so In my POV, R3 already isn't backwards compatible.
Maxim Olivier-Adlhoch
11-Sep-2006 23:34:46 I also agree that 'VALUE? SHOULD be renamed as 'DEFINED?
Sunanda
15-Sep-2006 8:57 By not making R3 backward compatible, none (in the worst case) of the existing published scripts will work with R3.
That means either the people who have published scripts (anywhere on the Internet, and elsewhere) will need to revise and publish an updated version to work with R3.
Or that R3 starts with close to zero available resources. And you can expect the first year or two's worth of support messages to be along the lines of "I tried downloading anamonitor/MySQL/etc" and it didn't work.
Microsoft invented the DLL hell. R3 may lead to an REBOL .EXE Hades. That's a problem that needs addressing before R3 emerges.
Pierre Johnson
16-Sep-2006 19:09:42 Sunanda laments,
"By not making R3 backward compatible, ... existing published scripts will work with R3 ... people ...will need to revise and publish an updated version to work with R3"

As Brian Hawley adroitly points out,
"It's not like REBOL 2 will magically stop working when REBOL 3 comes out."

REBOL is a tiny executable that runs even smaller scripts. Only old-timers are stuck in the past -- a past of resource constrained computing.
Having module namespaces makes REBOL 3 different. Making the new REBOL backwardly compatible is like putting a lawn tractor motor inside a Ferrari or like trying to sail with one's anchor dragging the ocean's bottom.
Carl should be shooting to make a product that is a tool much like Lotus 1-2-3 or dBase II were -- tools that enabled nearly anyone to compute.
Trying to make a more computer-science oriented product to appeal to nerds not only will make an also-ran, it's stupid.
Carl might as well kill the product now and invest in his wine growing and wine making.
Again, the start of this thread is to reveal that blogs are horrible tools for discussion. There is NO WAY for a person to initiate NEW, BETTER ideas.
All blog responders are at the mercy of whatever topic the blog writer chooses to introduce.

p3k
17-Sep-2006 7:53:56 pierre, how about starting your own blog to get into the position of initiating new and better ideas? it's really simple. and i am sure you stirred up enough curiosity to get your first bunch of visitors. thus, provide your blog's url and simply join the club of merciful blog writers.
Pierre Johnson
18-Sep-2006 13:34:18 p3k,
When reading your "contribution" to this thread, the first reaction is 'stupid posts what?'
Without going into deep explanation as to why -- suffice to say "REBOL is here".
Why discuss elsewhere?
Pierrot
21-Sep-2006 14:12:45 "It's not like REBOL 2 will magically stop working when REBOL 3 comes out." But it's exactly like working applications hat are built from publicly publish scripts will need to sensitive to which version of REBOL they were built from:
An R3 application may not be able to use any R3 resources. And vice versa. RT's own "What is REBOL" page states: The power of REBOL comes from its unique integration of programming language concepts and metadata language concepts. Except, it seems, that unique integration may not be possible with its own scripts, let alone any wider application.
Maxim Olivier-Adlhoch
21-Sep-2006 19:31:05 I might have an idea in a way to provide legacy support for R2 scripts.
instead of trying to make R3 compatible with R2 (which, like I pointed, is trying to seem almost impossible)... maybe it could be possible to have one or both of:

R3 module which provides a back door to R2 code, by loading it as R2 would and provide a view of it to R3... for example providing a spoofed system object within the R2 environment. In this case, people will not mind the RAM size... they know they are working in legacy mode, in theory trying out code, or updating it until it works natively. At least they can quickly "get things working". speed and size matter less to many of us than people think... as long as it works in the short term.

R2 mezz file which you can include at the begining of any R2 script to allow it to be understood within R3 interpreter (things like switching known word changes, supplying functions which are not available anymore, maybe even adding new words for converting or wrapping some of the datasets used by R3 which are programmed as R2 versions (ports, faces, etc).

These might not fix ALL occurences, but would allow some amount of code reutilisation either by fixing the old code, or allowing it to be loadable (still) in newer interpreter with minimal fuss.
Just recompiling faces from R2 to R3 (run-time, ex: view TO-R3-FACE old-face) might save a lot of work for many of us. Having a legacy port model within newer resource loading... at least old schemes can be loaded within a new wrapper, while they are converted(in this case if the original developer still is in the community!).
Just like the mac, things stay operational, while the good stuff gets upgraded to faster/newer/better procedures and capabilites.
DideC
22-Sep-2006 7:45:21 Not a bad idea Maxim.
Like the PS2 machine where PSone hardware (processor) where included for backward compatibility, why not just provide a Module to R3 that would be a complete R2 version (ie: the View.dll with a module linker).
Or keep it simple :
R3 is able to download an R2 interpreter and has a way to launch this R2 interpreter with a script as an argument.
The tricky part is : how to recognize an R2 script and an R3 one ??
Pierre Johnson
24-Sep-2006 3:42:10 Even simpler.
Like public scripts for the legacy REBOL 2.0 run-time?
Launch the legacy REBOL 2.0 run-time in a process (all contemporary operating systems support this) and run the REBOL 2.0 engine (just 650kb)
Next, have the run-time execute any script you want -- all day, everyday.
Want to run the latest and greatest REBOL 3.0 run-time?
SIMPLE: Launch it and write new scripts!
Want your customers to migrate to the latest?
SIMPLE: Sell them new scripts (script re-writes)!
Basically, you can continue to think backwardly or you can mature, embrace the new now and think forwardly -- new REBOL 3.0 and new scripts.

Scot Sutherland
25-Sep-2006 18:06:08 On the how to distinguish between REBOL 2.0 and REBOL 3. All REBOL 3 scripts will be labelled R3 or something. Otherwise they run on R2.
Pierot
28-Sep-2006 13:42:15 Scott, you are sugesting that all existing scripts would be rejected by the REBOL 3.0 run-time as they are not marked as REBOL 3.0 ready?

Comments on: Understanding the design flow of REBOL 3.0

Comments:

Post a Comment: