I don't recall anyone fighting to the death over someones syntactic preferences. Code written by experienced users (and Red codebase in particular) is a hard nut to crack, that's true.
Regarding development: I'd appreciate if you elaborate over your critique. Concrete suggestions on how development and testing processes can be improved are always welcomed.
And so on and so forth. I remember seeing a "status.tested" which added easily a hundred lines of new code with zero tests.
Funnily enough I see you've added a "test.written" label, which really shouldn't be there because that's what "status.tested" is for.
----
But forget issues and tests for the moment.
Out of 44 contributors to Red, only two have anything significant to contribute: the people who actually develop Red.
Of all the issues reported almost none contain code to fix the issue. Almost all issues are fixed by the same two people who develop Red.
Perhaps it's due to the fact that about zero percent of Red code is documented? Or that "Code written by experienced users (and Red codebase in particular) is a hard nut to crack"? Which is kinda ironic, considering how the authors and proponents gush about Red's simplicity.
Go back to the first issue in the list above. It's a one-line fix. So, surely, it could be fixed by someone else but the author of the language?
And since very very few of those lines are covered by any tests (even for issues reported and fixed), how is anyone except the two authors can ever fix those issues or contribute?
If "Code written by experienced users (and Red codebase in particular) is a hard nut to crack", how can you expect people to believe in it's "simplicity and fun"?
----
Bus factor - fair enough. Lack of tests - have you counted them? [1]
2/3 of issues you showed are purely formatting concerns, so I'm not sure what needs to be tested there. "test.written" refers to test being written in a testing framework, "status.tested" means that the described bug was tested in multiple development environments and confirmed. So your remark is slightly off the base.
Small number of dedicated contributors: historically, Rebol (the ancestor of Red) was developed by Rebol Tech company in a closed manner. So, IMO there developed a particular community mindset, where everyone just lets the Boss do the job and watches the action from the tribunes.
Another reason, like I said elsewhere, is the fact that Rebol never became mainstream, hence there isn't much contributors ready to provide the code of acceptable quality.
Lack of comments and such: in the early days, Red planned to be minimal and bootstrapped early, so the whole codebase was written in a throw-away fashion, with no comments or afterthoughts. As the project growed and roadmap changed its curves, community started raising demands (macOS View backend, new datatypes, supporting other platforms, the list goes on), so the "quick bootsrap" plan was ditched, but the code remained. This is a stumble block for other contributors, which, alas, will be moved away only after 1.0 is reached.
"Simplicity and fun" is completely off the point though, but I get what you say, even with a snarky tone. "Simplicity" here refers to the use of embedded DSLs, in which it is generally easy to express ideas suitable for a particular domain, and to "self-contained small toolchain" goal of the project. So, expressing ideas and developing them is rather simple, once you got the hang of the language.
Reading Red code requires a prior knowledge of function's arity and evaluation rules; ambitious projects require knowledge of multiple dialects and thorough understanding of core concepts; dynamic pieces (i.e. metaprogramming) can be challenging, unless you're coming from Lisp or Forth camp.
Runtime is written in Red/System dialect, which requires C-level skills to write. Red and Red/System share the same syntax, but require a huge mental leap to switch the context (Lisp vs. C dichotomy) - another 2 cents to your "lack of contributors".
I'm not a fan of "Red is simple and for everyone" sales pitch either - it's misleading at best, sets the wrong expectations and usually comes from people who barely clocked 1 hour in REPL tinkering with available View examples.
Hope that answers your concerns, more or less. If you want to alleviate them more quickly - drop by our community chat and start contributing piece by piece ;) Cheers.
> 2/3 of issues you showed are purely formatting concerns
This is a bald-faced lie, and one can see that by following the links I provided.
A "formatting concern" is changing indentation or splitting a long declaration over several lines.
The issues I've shown, and the majority of others, are actual bugs that are fixed by altering code.
> "test.written" refers to test being written in a testing framework, "status.tested" means that the described bug was tested in multiple development environments and confirmed. So your remark is slightly off the base.
It's entirely on point. Code for the fix is written, the issue is closed. The commit is merged into master branch. No tests are added in the commit that fixes the issue.
When are exactly tests for these changes "written in a testing framework", if ever?
I could count the tests until I'm blue in the face, but the fact remains: next to no tests are written for issues that are marked as fixed, and closed. And if you view the commit history, well, it's mostly fixes, and some superfluous tests remove. No commits show any tests added (I know such commits appear sometimes, for larger features).
> hence there isn't much contributors ready to provide the code of acceptable quality.
I don't even know how to comment on this
> This is a stumble block for other contributors, which, alas, will be moved away only after 1.0 is reached.
So, not in any foreseeable future. Original plan to release 1.0 was last year AFAIR. Then that shifted to release 0.6.5 AFAIR which is still not released.
So:
- contributors aren't willing to provide code of acceptable quality for any foreseeable future
- there won't be any acceptable quality, or even such an important thing as comments, for any foreseeable future
- there will rarely be any tests for any of the issues found and fixed for any foreseeable future
See why my skepticism about Red is not unfounded?
> Reading Red code requires a prior knowledge of function's arity and evaluation rules; ambitious projects require knowledge of multiple dialects and thorough understanding of core concepts; dynamic pieces (i.e. metaprogramming) can be challenging, unless you're coming from Lisp or Forth camp.
Do not confuse Red with Lisp. Lisp (and even its expanded dialects such as Clojure) have clearly pretty much defined rules on how to read code.
No "previous experience" with Red will let you parse the "simplicity" of
OS-draw-brush-pattern DC size crop-1 crop-2 word as red-block! cmd sym = fill-pen
> another 2 cents to your "lack of contributors".
It's not "2 cents". It's yet another weak attempt at finding excuses instead of facing criticism face on.
There's a reason I gave Elixir as an example. You could view it as a one-man show, as one contributor, the author, has an overwhelming input into the project compared to all other contributors.
However, it doesn't prevent him from:
- writing acceptable code
- writing tests for the fixes he provides to issues
- writing comments in code
What this result in? Well, even the issue I referenced: it was reported and fixed, and documented not by the author, but by a different contributor. A miracle, by Red standards.
> Hope that answers your concerns, more or less.
Nope, it doesn't. It's a string of excuses, and see the concerns about the foreseeable future above.
Which of the tests contain the test for the "Malignant output from react/link"?
Or, and I swear to God, I found this by pure accident trying to be snarky and digging up some old issue: your own reported issue, https://github.com/red/red/issues/3211
It was fixed, with no tests, and don't tell me it was "formatting concerns". So, which of the red/tests contain the test "being written in a testing framework"?
> This is a bald-faced lie, and one can see that by following the links I provided.
You call me a liar now? Tone down a bit, would you? By "formatting" I meant formatting output of error messages (changing size of the buffer down to 80) and data (ensuring that newline markers are preserved), not the source code cleansing.
> I don't even know how to comment on this
Then don't.
> Original plan to release 1.0 was last year AFAIR. Then that shifted to release 0.6.5 AFAIR which is still not released.
Not entirely correct. This [1] article gives a context to what 1.0 was "then" and "now", and also explain why roadmap was adjusted.
> See why my skepticism about Red is not unfounded?
By all means, be skeptical, I'm not trying to convert you or whatnot. You've raised important points, so I tried to elaborate and explain why things are the way they are, so you can judge by yourself.
> Do not confuse Red with Lisp.
Well, I don't. As I said, reading code requires knowledge of funciton's arity, and your example only proves that. And you seemingly ignored what I said about "simplicity". Moreso, your example is Red/System, not Red, pulled out of Draw backend. I can similarly crop a random snippet out of the guts of Elixir and make googly eyes.
> It's yet another weak attempt at finding excuses instead of facing criticism face on.
Again, tone down. I asked you to elaborate exactly to face the criticism, and provided some context, so you can make a fair judgement. Things turned out that way for reasons - I gave you my IMHO on them - you see these reasons as "excuses". Fine, point taken.
> see the concerns about the foreseeable future above
> You call me a liar now? Tone down a bit, would you? By "formatting" I meant formatting output of error messages (changing size of the buffer down to 80) and data (ensuring that newline markers are preserved), not the source code cleansing.
1. Once again, this is provably false.
2. Once again, this is no jsutification for the fact that nearly all bugfixes contain no tests.
> You've raised important points, so I tried to elaborate and explain why things are the way they are, so you can judge by yourself.
I have, and my initial an subsequent posts remains just as valid.
> Time will tell.
It has already told. At best, Red sees one minor version increment per year. At best. It's more of a one patch version increment per year.
So, going back to this statement: "hence there isn't much contributors ready to provide the code of acceptable quality.... [lack of comments as] a stumble block for other contributors, which, alas, will be moved away only after 1.0 is reached." This means that we will not see this for any foreseeable future.
Somehow this is viewed as a normal course of events even though it isn't.
Well, to each his/her own, I guess ¯\_(ツ)_/¯
BTW, have you ever seen any tests to your own bug reports, or have you written any tests for the bug reports where you provided a fix?
If it's provably false, then take your time to actually prove it before calling someone a liar.
> my initial an subsequent posts remains just as valid.
They remained as biased as the were. You waved away project's history and keep imposing "high" standards pulled from other projects, without respecting their retrospective history and goals.
> At best, Red sees one minor version increment per year. At best. It's more of a one patch version increment per year.
Absolute nonsense. Read the changelogs, roadmap and Github releases before making such claims.
> Somehow this is viewed as a normal course of events even though it isn't.
Again, in retrospective, this is an expected course, and no one will adhere to your idealistic, unencumbered by reality version of how things should be done. Want an overnight improvement - start contributing.
> Well, to each his/her own, I guess
I guess. Feedback filtered out of your messages is appreciated, and taken into account. Thanks for taking your time to respond. In the meantime, I'm marking this as the end of discussion.
Barely above one patch increment a year for the past three years:
- Nov 2018, 0.6.4
- Jul 2018, 0.6.3
- Mar 2017, 0.6.2
- Jun 2016, 0.6.1
- Mar 2016, 0.6.0
Minor versions incremented from 0.1. to 0.6 in 7 years, and increments have slowed down.
So, we are expected to believe that 7 years from now when it maybe reaches 1.0.0 the devs will suddenly go through all the code, add comments and tests, and start caring?
> no one will adhere to your idealistic, unencumbered by reality version of how things should be done.
Me: when you fix issues, you should really add tests to those fixes. At least strive to have more than ~0 tests in your fixes. Add documentation to critical parts of your system.
You: "your idealistic, unencumbered by reality version"
:-\
That's why I'm extremely sceptical. What is considered the norm pretty much everywhere is viewed as "unencumbered by reality" in Red world.
> Feedback filtered out of your messages is appreciated, and taken into account.
Dimitri, you've obviously looked into Red in some depth, which is appreciated. And your comments and criticisms have been heard. It's easy for miscommunication to occur in chat like this, so we can probably close this particular thread of conversation, as I don't think it's productive anymore. As much as I now want to chime in to defend our position, it wouldn't help. You make valid points, but comparisons with other projects are hard.
If you don't like Red, or how the project is being managed or progressing, that's fine. Sharing what you've learned is also great, as long as others can form their own opinions from facts presented (again, hard to present deep info in chat). All we ask is that you try to be fair, and think about how harmful negative press can be to a project. When you've put a huge amount of time and effort into something you believe in deeply, it's easy to get defensive when someone criticizes it (in ways that may seem unfair).
How things are said is important, as well as balancing pros and cons. In re-reading the chat, I admit that I got defensive, which is why I didn't respond initially.
In conclusion, can we do better? Yes, of course. Is much of the code written by a very small core, who knows the system well, and isn't writing it with the expectation that others will read and learn from it? Yes. Can we do better on testing? Yes. Do we already have more than 30'000 tests? Yes. Are those core devs pretty darned amazing, considering what they've built (insert feature list here :^)? You bet they are.
Red isn't for everyone. Our approach won't be to everyone's liking. But we hope people will be fair, wish us luck, and maybe even applaud us for trying to build something that will make their lives better. At the very least, we hope they won't talk us down unfairly.
You haven't really looked at the fix, nor do you understand what the issue is about...yet you think you are warranted to emit a quality judgement about it.
The issue is about `react/link` function generating a too long output when it encounters an error. That output includes references to potentially heavy graphic objects spreading over dozens or hundreds of lines, while the user only needs the beginning of that output (one or two lines), in order to identify which reaction code is concerned by that error.
The fix restricts printing everything using `probe code` to printing only the first 80 characters `print mold/part/flat code 80` (adding a flattening too using `/flat` refinement to remove eventual line breaks in that output).
This is typically a case where no test is needed nor desired, because:
* it is just about shortening a part of the output in an error report to a decent size instead of letting it go unchecked. It has no possible side-effect on anything else in the codebase.
* the replaced code cannot fail in any way, as `mold/part/flat` will deliver a properly cropped and sanitized string regardless of what `code` refers too. And that is guaranteed by the unit tests on `mold` in the tests suite. [1]
If someone would submit a test for such fix as a PR, it would be rejected at once, as it would be a waste of time/bandwidth/storage/resources. Its author would be viewed as very naive, or extremely dogmatic, as you are here in your posts.
On the principle, that one should have a regression test added, I agree. But I did not add one because:
* this function is just for visually formatting blocks by adding a new-line marker at desired place(s). This is rarely used function, and with the `/skip` refinement, it is an extremely rare occurence in user code. In the Red codebase, out of 157 occurrences, `/skip` is present only 5 times, and only in Rebol parts, not Red parts, so unaffected by this fix.
* this function has no impact on the rest of a user app code, as it is used only for pretty-printing some outputs in the console. New-line markers could, in theory, be misused to be the base of some funky algorithms, but I have never heard of anyone ever doing that in Rebol or Red world.
* this simple case can be left for a contributor to softly start learning about Red language and our testing framework, while doing a useful contribution. Each missing `test.written` tag in a fixed ticket is a good opportunity for contribution.
Therefore, the regression risk associated with not writting any test for this feature is extremely low. So, in such case, I am willing to trade the time to write the tests for that, for making another fix, or advancing on another feature. In a future batch-processing of those missing tests (as explained in detail in another post), or once we reach the "catch-up" stage in 0.9, if nobody did contribute it, we will write the tests for this one, in order to reach full coverage. I don't expect a dogmatic programmer to understand this kind of trade-off, anyway.
> 3. stack overflow on limited append/insert, https://github.com/red/red/issues/3705
> The fix contains a single test even though the issue provided three different failure modes
Correct. Though, `append` is a shortcut for `head insert tail`, so the `append` features are implemented inside `insert` native function. The provided test seems to only cover `insert/dup` case:
--assert 5000 = length? head insert/dup #{} #{20} 5000
but actually, it covers both, because the implicit `tail` in `append` has no effect on an empty series like here (the `#{}` binary series). So `head insert/dup #{}` or `append/dup #{}` are both going through the same code paths internally. The only diverging path is on the last 2 changed lines of the fix. Though, other existing tests in the test suite are already covering that [2], so no worries.
For the third case, it's indeed missing, and the probable explanation is that the developer missed it, as it only appears in a later comment in the ticket, and not in the main description on top of the ticket.
> I remember seeing a "status.tested" which added easily a hundred lines of new code with zero tests.
The only parts I can think of where hundreds of lines of new code would not be covered by at least some tests are in the View module (our GUI library). Those kind of tests are usually very costly to write, complicated to test properly (because of different rendering on different OS), and hard to automate on our headless CI servers. Though, even there, we try to do something about it, by providing a prototype "null" backend [3] for testing at least the platform-independent parts of the View engine, and we got also recently a contribution for testing some image-related features on Windows platform. [4]
qtxie and dockimbel are the two main contributors to the repo, they weight a total of 139 commits, while the others together total 50 commits. This gives the following ratios:
main ones : 73%
others : 27%
So more than a quarter of the last 6 months fixes are made by other than the two main contributors. So much for the exaggerated claim...
> Perhaps it's due to the fact that about zero percent of Red code is documented?
So comments don't count as documentation now? See my other replies for the comment stats.
> Or that "Code written by experienced users (and Red codebase in particular) is a hard nut to crack"?
10 different non-main contributors provided 27% of all the fixes in the last six months. They must be incredibly smart or, maybe mind readers in order to achieve that, right?
Let me propose another explanation: maybe the source code is not that difficult to understand, as you desperately try to misrepresent it in this whole thread? Maybe, with the help of the rest of the community, contributors can figure it out, even with low amount of documentation?
Maybe your all rambling here is just is because you wanted to contribute, but expected a "first-class" treatement, didn't find a full documentation offered to you on a golden plate, so went on a bashing/trolling session here on HN, in a pathetic attempt to discredit our work? That sounds as a likely explanation of your passive-aggressive tone, dishonesty and wilful ignorance in your posts here.
> It's a one-line fix. So, surely, it could be fixed by someone else but the author of the language?
Lol...that's hilarious. So the author of the language is forbidden from making fixes to his own creation, like a oneline-fix if he wants to? No kidding! The way that specific ticket was reported could have let think that the root cause could have been a deep issue in the reactive framework. So, while screening the tickets, as the author and maintainer of the reactive framework code, I identified this ticket as for me to explore, then ran the code to reproduce the problem annoying the reporter, and immediatly identified an harmless excessively verbose output on reactions processing errors. At this point, stepping into the code to make a one-line fix was the right thing to do, as I already spent time on investigating it.
> 336 lines of no significant comments other than trivia for the author himself.
How dishonest again... What you call "trivia for the author himself" are actually very important comments, as they are good clues for some more complex parts of the code. So now, even when you find comments in the code, you dismiss them as "not significant" and "for the author himself"... Moreover, you don't mention the 20 docstrings that document the public functions interface in that file, nor the full reference documentation [1], that cover all the features implemented in that file...
> "New line flags not cleared" whose fix is just a few lines? Oh, it's in a 3000-line file with no comments
"no comments"? I count 125 lines of comments there...more dishonesty. This file is the recipient for the low-level part of about 100 "native" functions (`native!` datatype at user level). All those functions are independent from each other. Their size ranges from 2 to 90 lines, with a significant number of small trampoline functions, and the code there is very explicit. Each native's interface is fully described with docstrings in [2]. If there is some significant extra commenting efforts to do in the codebase, it's really not in this file.
> And since very very few of those lines are covered by any tests (even for issues reported and fixed)
Proven wrong in details in other replies.
> how is anyone except the two authors can ever fix those issues or contribute?
Demonstrated at the beginning of this post.
> If "Code written by experienced users (and Red codebase in particular) is a hard nut to crack", how can you expect people to believe in it's "simplicity and fun"?
That's a non-sequitur. A complex system can have a simple user interface. In our case, most of the codebase in written in Red/System, for system programming purpose. System programming is far from simple or fun for most people, yet that has no bearing on Red, which lives at a higher abstraction level, and that users are enjoying for its "simplicity and fun". Can Python be simple to use, even if it's implemented in complex C code?
Why should I engage in a discussion with a spiteful passive-aggressive internet troll whose responses are part thinly veiled and part clear ad hominem attacks?
Also, you misquote, misrepresent and misunderstand the vast majority of my words. Oh well, good luck building your fantasy world.
Regarding development: I'd appreciate if you elaborate over your critique. Concrete suggestions on how development and testing processes can be improved are always welcomed.