6 ms·
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 nu
by 9214 8y ago
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.
- dmitriid 8y ago> Regarding development: I'd appreciate if you elaborate over your critique. There's nothing to elaborate, really. If you list all "status.tested" issues, how many are tested? Let's take the top few as of today. 1. Malignant output from react/link, https://github.com/red/red/issues/3713 https://github.com/red/red/issues/3713 fix: https://github.com/red/red/commit/644be4b1e3bfcf70a5f9f5e0066fdd2cc964cd73 https://github.com/red/red/commit/644be4b1e3bfcf70a5f9f5e006... One-line fix, sure. Where's the test? 2. new-line flags are not cleared on subsequent calls, https://github.com/red/red/issues/3707 https://github.com/red/red/issues/3707 Fix: https://github.com/red/red/commit/b7ee2846b58a1328d57002b3ed2d076d65ca4b7e https://github.com/red/red/commit/b7ee2846b58a1328d57002b3ed... Severl line-fix. Where's the test? 3. stack overflow on limited append/insert, https://github.com/red/red/issues/3705 https://github.com/red/red/issues/3705 The fix contains a single test even though the issue provided three different failure modes: https://github.com/red/red/commit/bd41d35ee5a73cd5779647b50376b0d757c9e8a0 https://github.com/red/red/commit/bd41d35ee5a73cd5779647b503... 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? Too bad the file where the issue is fixed is this: https://github.com/red/red/blob/644be4b1e3bfcf70a5f9f5e0066fdd2cc964cd73/environment/reactivity.red https://github.com/red/red/blob/644be4b1e3bfcf70a5f9f5e0066f... 336 lines of no significant comments other than trivia for the author himself. "New line flags not cleared" whose fix is just a few lines? Oh, it's in a 3000-line file with no comments, https://github.com/red/red/blob/b7ee2846b58a1328d57002b3ed2d076d65ca4b7e/runtime/natives.reds https://github.com/red/red/blob/b7ee2846b58a1328d57002b3ed2d... And so on and so forth. 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"? ----
- dmitriid 8y agoAs a separate comment. Let's consider Elixir, for example. Issue: EEx multiple callbacks with `-> %>…<% end` format, https://github.com/elixir-lang/elixir/issues/8590 https://github.com/elixir-lang/elixir/issues/8590 Fix: https://github.com/LostKobrakai/elixir/commit/d33fdb57d457dd8bd845f05389e7bc7096cae3f6 https://github.com/LostKobrakai/elixir/commit/d33fdb57d457dd... It describes what the code does in a comment, there are tests. The file itself contains comments crucial to understanding: https://github.com/LostKobrakai/elixir/blob/d33fdb57d457dd8bd845f05389e7bc7096cae3f6/lib/eex/lib/eex/tokenizer.ex https://github.com/LostKobrakai/elixir/blob/d33fdb57d457dd8b... Compare this to any Red issue, fix, or any source file in the codebase
- 9214 8y agoBus 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. [1]: https://github.com/red/red/tree/master/tests https://github.com/red/red/tree/master/tests