 |
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.
|
 |
Updated 7-Mar-2024 - Copyright Carl Sassenrath - WWW.REBOL.COM - Edit - Blogger Source Code |