Here are a some facts about Red to debunk your attempt at spreading false information, like the "no tests" and "no comments". For the record, we have written a large number of unit tests (in addition to the regression tests mentioned above) since the beginning:

* 22196 tests for Red (with ~10k of them running once for the compiler, once for the interpreter)

* 9847 tests for Red/System

Without this large test suite, the development of Red would simply be impossible. Though, the features coverage is still not exhaustive, as we are still lacking tools for measuring it (contributions welcome!).

Now for the supposedly total absence of comments, here are some stats from red/red repo extracted using a simple Red script [1]:

-- Type -- FileCount -- LOC -- Comments -- Cmts/LOC (rounded to nearest integer)

.r 39 25186 3507 14%
.red 48 16495 776 5%
.reds 154 85742 7687 9%

Basically, .r represents our toolchain code in Rebol, while all the runtime and standard library are in .red and .reds (Red and Red/System respectively).

Those ratios are not bad, but could be better (10-15% in each category would be a good goal). More comments could be still added in some complex code sections, though embedding a full documentation of the code, in the code, is not our approach (see more explanations below). As an extra note, I have noticed a pattern with wannabee contributors with no system programming skills, of thinking that heavy commenting in the runtime low-level code would magically make them become system programmers...

The plan has always been to provide architecture-oriented documents and code maps to ease the navigation for core contributors. Though, the core team does not have the resources for now to do that, as our short/mid-term roadmap is already overloaded. Some of our contributors have documented some parts, but those docs are scattered around, and in multiple languages, not necessarily in English.

I am also taking this opportunity to address those points from a higher perspective. Given:

* the unusually large spectrum of the project for a programming language (stack of multiple languages, very rich standard library, cross-platform, self-contained,...),

* the bootstrapping process that would lead us to the aimed selfhosted Red in 2.0,

* the funding needs to sustain the project both in short/mid/long-terms,

* our business goals (in addition to the purely technical ones),

* expectations of low number of contributors until 1.0 (due to some unique aspects of our stack),

we have strived to find ways to go as fast as possible through the bootstrapping phase. So since the beginning, we have taken shortcuts, to implement the features needed for 1.0 as quickly as possible. That means less comments in the code (as the team is small and work at the same location), postponing the writing of many regression tests, postponing some design decisions and some edge cases processing, writing only minimal survival docs for the team and close contributors.

So, FYI, there is a "catch-up" stage planned between 0.9 and 1.0, where we will address those gaps, as we want a rock-solid and properly documented, 1.0. Moreover, when all design decisions are not set in stone, systematically testing/documenting all the features or code parts that may be dropped later is not winning move. In practice, regressions are rare in Red codebase, so the missing regression tests are not a show-stopper either, and we can live with that until 0.9.

[1] https://gist.github.com/dockimbel/2af078e02e56fcc092aea771de...