> 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?
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?
I doubt that.