Red Programming Language: Plans for 2019

Let's consider Elixir, for example.

Issue: EEx multiple callbacks with `-> %>…https://github.com/elixir-lang/elixir/issues/8590

Fix: 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/d33fdb57d457dd8b...

Compare this to any Red issue, fix, or any source file in the codebase

Red is implemented in Rebol2. That also comes at a cost due to Rebol2 not being free/libre and being abandoned.

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

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

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.

> [1]: https://github.com/red/red/tree/master/tests

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"?