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.
> 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:
Yeah. If you only paid attention to what I wrote.
Here's verbatim what I wrote (fixing typos only):
Patching holes are usually like this:
- issue is raised on GitHub
- it's acknowledged
- a fix is written (with zero comments even for the complex issues) and merged
And this is an easily verifiable fact of life. I know that there are tests covering the bigger features.
> 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.
Once again, you fail to understand what I wrote. While architecture-level documents are fine, and should be written, the codebase itself is entirely undocumented. It's nice that you yourself understand it. Hardly anyone else does.
To rephrase that: there are ~100 000 LOC of undocumented Red code. The percentages you show are mostly comments like "EXPORTED FUNCTIONS" or one-liners that you as the author may understand. Or these beauties: https://github.com/red/red/blob/master/runtime/parse.reds#L1...
Any file you open, it's a vast landscape devoid of any meaningful comments describing what things do, how they do it, what to expect etc.
> 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
So, I'm looking at current speed of development and version increments. 0.9-1.0 looks to become reality in 5-7 years' time, and this is actually fine. However, you expect me to believe that you will go in, document all the Red code that will have been written by that time, and go and retroactively write tests for all the issues you fixed in the meantime?
* 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]:
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...