I do not appreciate your remark about our community and Czech-speaking part of it. This is rude and uncalled for.
Regardless of gender and nationality of community members, and despite the fact that Red is an alpha software, the following projects were created, which may qualify as highly visible:
* neural networks [1]
* computer vision framework [2]
* dataflow engine [3]
* ports of (cross-platform) GUI widgets [4]
* projectional editor [5]
* drawing apps [6]
* operating systems (an in-house project as of now, so no link)
If you don't know what to make out of Red, I'd suggest to grab the latest build [7] with a list of learning resources [8] and do a bit of research. Official About page [9] also gives a good list of main features.
Big libraries indeed aren't necessary, because most of batteries are included in a 1MB executable, and common needs are covered by core library. Full-fledged module system is missing, but is planned for 0.8.0 release. We also have a large Rebol ecosystem, from which various scripts and applications may be ported, if necessary.
> I do not appreciate your remark about our community and Czech-speaking part of it. This is rude and uncalled for.
No offense was meant -- wizardry is no bad thing in my estimation, and the Red community seems like it may have a lot of Czech wizards in it. The juxtaposition with cult is meant to convey my confusion; I can't tell a cult from a cabal of wizards. Nor do I mean to imply that a language barrier is anybody's fault. A language barrier is a natural feature of the internet, like a river separating monolingual anglophones like me from Czech speakers. The point of my comment is that reading about Red always leaves me puzzled. I'm afraid your links, which I've followed to a depth of 1, have failed to dispel my confusion.
Like I said, the best way to dispel the confusion is to play with Red by yourself and ask question in community chat. It is puzzling at first, but clicks over time.
>I do not appreciate your remark about our community and Czech-speaking part of it. This is rude and uncalled for.
There was no offense being given. In my experience there isn't sympathy for crying wolf here, and doing so only serves to harm whatever else you have to say.
"Wizardry" surrounded by "cult", "no highly visible projects" and "shortcomings", followed by unbacked focus on a particular national group reads more like "quackery" to me.
I get that meaning might be lost in translation, but also think that it's fair to assume the worst, esp. on an Internet forum.
I'm not the OP (and not associated with red an anyway, other than being a fan of REBOL), and I agree the wording deserved to be called out. "cult" and "Czech wizardry" aren't exactly positive framing words. Hopefully this doesn't spiral into a discussion about PC comments, because red looks to be cool and deserves a good technical discussion; but I don't think 9214 was off base calling out the comment.
It could be a compliment of course, like "wow, this stuff is amazing tech wizardry that should be much more appreciated, and probably would be if not for the language barrier!"
Let's just agree that natural languages are too fuzzy and ambiguous and assume good faith.
Frankly, I don't get what Czech has to do with it and why it was mentioned.
Major part of old-timers (from Rebol era) in our community are indeed Czech people, but Red development was initiated in France, moved to China, and now bridges people across the whole Europe.
Putting such emphasis on nationality without any clear reason IMO looks strange and raises my eyebrow, to say the least.
It’s not the end of the world if there are no highly visible projects. You’ve listed 6 things, but at a glance I don’t think any of them are highly visible.
Unless... there was a language barrier which obscured the meaning of “highly visible” which would be pretty funny in an ironic way.
> > If anything, it sounds too easy, making me think "what's the catch?
> This is rude and uncalled for.
I think she/he raise a fair point about how the Red language is advertised, and it's actually a rather friendly to assume that it's due to language barrier.
Many posts about Red/Rebol are unequivocal praise with very few details or any acknowledgements of short-comings or limitations of the languages.
Just to dig up some random ones:
Here's a speed comparison between Rebol and Python[0]: Rebol is faster (surprise!), but the post doesn't contain or link to any of the code used for the comparison
Here's some grand self-praise from the Why Rebol/Red[1] on why it's just better than all other languages:
> You may be familiar with Clojure, Python, Ruby, Lua, frameworks like Ruby on Rails, or any of the multitude of Javascript frameworks which are purpose-built to "ease" particular types of development work. Such languages/tools/environments are certainly productive compared to traditional tools like plain old C++, Java, etc., but they are absolute behemoths when compared to Rebol. Virtually every other well known development tool in popular use is built upon bloated layers of existing technology, and encumbered by mainstream language syntax and development procedures which introduce an extraordinary volume of unnecessary complexity at many levels. Most developers have just never experienced the sort of self dependent architecture, lightweight tooling, bare language and data structure syntax, composability, and reduced code volume, which Rebol prioritizes as its most important purposes.
(Are Red/Rebol creators seriously claiming that Clojure's syntax is complex?)
Of course there are sometimes programs about which you could make grand claims, like when SQLite claims to be "35% Faster Than The Filesystem"[2], yet they also clearly describe its limitations[3].
Edit: Even in this thread we get this kind of praise:
> Isn't Red a great language to teach children? I just tried Red and it's amazingly simple to get started.[4]
About a year ago I did try out Red and Rebol, and I couldn't get any of the examples to work, or figure out what the syntax meant, because there's just so many cool examples of how few lines it takes to do X but very little explanation. It made me feel a bit inadequate, because if this language is soooo easy to use, and yet I somehow fail to grok it, then I'm just not smart enough, right?
Here's one of the examples linked to in Why Rebol and Red, with hardcoded IP, no comments and all:
REBOL [title: "Live Camera Video Stream"]
for i 2 27 1 [append b:[] rejoin [http://207.251.86.238/cctv i ".jpg"]]
view w: layout [
i: image 320x240 text-list 320x200 data b [forever [
set-face i load value wait 1 if not viewed? w [unview break]
]]
]
It's great that someone found that so easy to write, but it looks like one-off write-only shell script, and is certainly not useful for "teaching children".
I know it might seem a bit harsh that I'm suggesting that Rebol/Red is being promoted in a somewhat dishonest way, but I'm mentioning this so that you could hopefully improve, not to make you upset.
One of the reasons is that the Red community is very small and entrenched. They know everything that comes out of the language, and to them everything is easy and understandable.
They will fight you to the death if you even try to say that "english-like syntax with no parantheses" is the opposite of readable or understandable when you don't know the system.
Go into any of Red's source files and you will end up looking at dozens to hundreds of lines of code with no comments and which often look like this:
return old-gradient-pen DC cmds start tail cmd sym catch?
OS-draw-brush-pattern DC size crop-1 crop-2 word as red-block! cmd sym = fill-pen
_read opfd hash alg-digest-size type
etc. These are obviously impossible to look up and find.
The whole development is haphazard as well. Everything hinges on two may be three people who know Red internals wihch frantically move from subsystem to subsystem developing features and patching wholes.
Patching wholes are usually like this:
- issue is raised on GitHub
- it's acknowledge
- a fix is written (with zero comments even for the complex issues) and merged
- the issue is closed with a "tested" label [1]
About 0.001% of "tested" issues contain any tests. The majority of fixes are apparently only fixed and manually tested against the reported issue.
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.
Development is far from haphazard, but we're always open to examples of how other projects we can learn from, as long as it's a fair comparison and the resource and organization aspects align enough that we can leverage things we learn.
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?
Not liking Red is understandable. Programming languages, as largely subjective HCI, cannot appeal to every single software developer. Though, that is not a reason to be dishonest, and trying to paint a bad picture of our work (even in fallacious ways, as demonstrated below).
> One of the reasons is that the Red community is very small and entrenched.
"Entrenched" is just your opinion, not a fact. Given the rest of your post(s), your opinions about the Red project are demonstrably uninformed and highly subjective.
> They know everything that comes out of the language, and to them everything is easy and understandable.
If the core Red team and main contributors didn't "know everything that comes out of the language, and to them everything is easy and understandable.", that would be very worrying, don't you think so?
> They will fight you to the death if you even try to say that "english-like syntax with no parantheses" is the opposite of readable or understandable when you don't know the system.
Exaggerated, like your whole post. We have civil discussions with people who are actually interested in discussing about Rebol and Red. [1] From the way you sound, I am wondering if you might be one of the few arrogant people who show up on our online channels from time to time, trying to lecture us about "their right way" using a condescending tone...usually, that does not end well.
Fortunately, such bad encounters are rare. We often get lispers showing up from CL, Scheme, or even language authors, like Joe Armstrong (Erlang's author) on our Gitter chats in 2017 IIRC, who liked Red and labelled it a "fun" language. Though, Joe was later upset by our branching into the blockchain world, like a few others in the community, but I hope they see now that we did it for good reasons.
> Go into any of Red's source files and you will end up looking at dozens to hundreds of lines of code with no comments and which often look like this:
return old-gradient-pen DC cmds start tail cmd sym catch?
OS-draw-brush-pattern DC size crop-1 crop-2 word as red-block! cmd sym = fill-pen
_read opfd hash alg-digest-size type
Patching together cherry-picked lines of code from different Red/System files, with zero context...how dishonest. (I give a detailed context and explanation about those lines you have extracted from different sources on a separate page [8], as it is quite long. It also debunks your "no comments" claim as the first line you have picked has 3 comments in the neighbouring lines.)
So, you went to cherry-pick low-level code parts in Red/System, involving OS API calls, for what? For making a preposterous statement like "These are obviously impossible to look up and find."?... Those lines of code are not mine, though it took me only a few of seconds using a basic code editor (not even pulling VSCode with the Red plugin) to fetch the information needed to fully understand those expressions...so much for the "obviously impossible to look up and find"...
People are using free-ranging evaluation in Red and Rebol code since 20 years, and readability is not something users complain about (they were certainly many other issues to complain about, but that is not one). On the contrary, it is one of the Rebol features I have found the most attractive, as have many others. I can understand that your mind is not wired for that, and that you don't like it, but that's not a reason for getting angry at us, nor at Red. The sad part is that you don't even bother asking why such design choice was done in the first place, and what is the aimed trade-off behind it...that speaks volume about your real agenda here.
> The whole development is haphazard as well.
Great, another armchair expert on Red! You are obviously not a Red contributor, I doubt you are a Red user either, so you really have no clue about the project's history, nor goals, nor organization, nor its real-world constraints (at this point, I don't think you care at all anyway, you are just here for bashing). Funny how you jumped from a feature of the language syntax to development process. Your post is really not meant to inform anyone, but only to cast negativity over the Red project...for no good reason.
> Everything hinges on two may be three people who know Red internals wihch frantically move from subsystem to subsystem developing features and patching wholes.
Let me rephrase that properly for you: "The core Red team is working very hard, despite being small, on many different sub-systems, restlessly implementing new features and fixing issues, making the Red users and community happier every day!".
So now being a small, but very capable team is something bad? As you praise a pretty much solo-project later, I don't get the rationale there...double standard I guess. Moreover, you don't even know what you are talking about (again). I can count at least 7 people in the Red community, including the core team, capable of working on the Red internals, adding features or fixing bugs. Maybe it has escaped your understanding, but we are building a stack of programming languages (with lot of system programming), and not a web site. The skills and experience required for properly doing such work are very rare. The few capable people also have real-life constraints, so the permanent core team capable on working on the internals is currently 3 people, with additional 2 or 3 more working on their spare time. We are lucky and grateful to have that many capable people with us already. We are still in the early days, with an alpha Red, so having a small compact team is rather an advantage, as there is still significant design to do.
> a fix is written (with zero comments even for the complex issues) and merged
From 10 days ago, ticket #3692 [2] referenced a hard to reproduce complex crash (an heiseinbug), and includes a few hundred lines of detailed explanations about the debugging process, including some screenshots.
I usually only comment some fixes when the explanation or fix is not obvious for the team. Sometimes, the comment is just put in the commit log. Systematically commenting all fixes would be useless anyway, as many fixes are straighforward, or simply don't deserve any comment (like the "Malignant output from react/link" [3] one you've pointed out below). Moreover, we have a strong presence on our Gitter chat, and are always happy to help contributors ramp up when needed. If someone thinks that a particular fix requires a comment or explanation, we are always glad to provide it.
> About 0.001% of "tested" issues contain any tests. The majority of fixes are apparently only fixed and manually tested against the reported issue.
You are implying here that tests for bugfixes are non-existent. Let's put your extravagant claims to the test (pun intended):
- 1076 tickets with `status.tested` and `type.bug` tags [4]
- 52 tickets with the extra `test.written` tag [5]
That gives a 4.83% result...so about 5000 times more than your claim! That's what happens when you are pulling fake numbers out of your ass. Moreover, as you are wilfully ignorant about Red project (confirmed by your other posts), you don't know that:
* the tests are sometimes provided in a later commit (using a `TEST:` prefix in the log), not necessarily within the fix commit.
* some tickets get a test written, but the `test.written` tag is not set (no stats there, not sure how many)
* we do try to address in batches the missing regression tests for fixes, from time to time.
The last point has led to the creation of a specific test file [6] that gathers tests written in those batch sessions. I count 242 more tests there, so it gives a total of 294 written tests for fixes, about 27.3% as the final result. So much for the "0.001%"...
That result is surely not satisfying though, even if 100% is not a goal there, as explained above, we should get a much more complete coverage for bugfixes.
> etc. etc.
Typical ending for a FUD-spreading post... The only honest statement from you I can find is your Twitter account's baseline [7]: "Opinions on things I know nothing about". That sums up well your posts here about Red.
> Patching together cherry-picked lines of code from different Red/System files, with zero context...how dishonest. (I give a detailed context and explanation about those lines you have extracted from different sources on a separate page [8], as it is quite long. It also debunks your "no comments" claim as the first line you have picked has 3 comments in the neighbouring lines.)
1. I was looking for exaggerated examples, that's true. It's hardly cherry-picking as lack of parantheses to discern between functions and arguments makes it really hard to read/understand code everywhere
2. How nice of you to provide comments. Which are:
- not even in git, but on pastebin
- Instead of putting that extended description in the code comments, you put them... somewhere.
So far it doesn't look so good for you.
Let's look at the "three neighbouring comments". They have no meaning for anyone looking at the code who's not already familiar with the code. I'm really glad that you said that "we need at least two stops". It makes so much sense.
And, in the end, it still doesn't help the long line where you have no idea what is a function call, and what is just an argument.
Well, unless you scan the entirety of the code because something may be function defined somewhere in the file, some may be variables, some may be something else.
So, so far you've only validated everything I said.
> That gives a 4.83% result...so about 5000 times more than your claim
Wow. You've really, really "put my extravagant claims to the test". Well, you've actually just reinforced my words. A tiny fraction of all bugfixes ever get tests.
> the tests are sometimes provided in a later commit
> we do try to address ... from time to time
I will remain skeptical, as it's really hard to correlate a bug fix and a test that "may be sometimes from time to time" written at a later date.
But it looks like even your ardent supporters don't know about those tests.
Moreover, this approach clearly affects how people approach writing the system. "Oh, there are no tests for the bugfixes, and no comments in the code? when I submit my bugfix, I'll do the same".
> The only honest statement from you I can find is your Twitter account's baseline [7]: "Opinions on things I know nothing about".
Yup. The person accusing me of being arrogant and condescending goes to great lengths to find out who I am and revert to ad hominem attacks.
> And, in the end, it still doesn't help the long line where you have no idea what is a function call, and what is just an argument.
And still people have no issue reading and writing code in Rebol and Red. And still 10 non-core team programmers provided a quarter of the bugfixes in last 6 months... It's either magic, or it's you trying desperately to paint a bad picture of Red, without any interest at all in understanding it.
> > That gives a 4.83% result...so about 5000 times more than your claim
> Wow. You've really, really "put my extravagant claims to the test". Well, you've actually just reinforced my words. A tiny fraction of all bugfixes ever get tests.
And yet, more dishonesty again... You've picked up the intermediary value in my demonstration above, and not the final one: 27.3%. So 27% is a "tiny fraction"? Makes sense. You are that desperate now to resort to cheap tricks like that?
> Yup. The person accusing me of being arrogant and condescending goes to great lengths to find out who I am and revert to ad hominem attacks.
Googling your HN id is certainly not "going to great lengths", and I was curious about your background. From your first post in this HN thread, you have clearly shown aggressivity, misrepresentation, wilful ignorance and dishonesty towards Red project, as I have proved several times, like this "0.001%" of bugfixes having tests, while the reality is 27.3%. Where's your apology for posting fake information on HN clearly meant to mislead readers?
> A real class act you are.
That is left for the crowd to judge, as is your performance in this whole thread. You have missed a good opportunity to actually have an interesting discussion about a new language that is attempting to go in a different direction. And surely, we are far from perfect, but that does not warrant such misplaced anger from the start towards us and our work.
> (Are Red/Rebol creators seriously claiming that Clojure's syntax is complex?)
Red's author here. I have nothing to do with those websites nor their content. They are not official Red nor Rebol sites. I do not see a single quote from me there, nor from Rebol's author. Stop spreading false information please.
By definition, "official" is what is published by the Red core team, on our official channels. We try to support and encourage the efforts of our community members by linking their site from the official Red site. That does not mean that we control nor endorse all the content there.
> encumbered by mainstream language syntax and development procedures which introduce an extraordinary volume of unnecessary complexity at many levels.
This clearly states about Clojure that its syntax AND it's procedure of development (another grand claim) introduce said complexity.
That whole write-up is just about as incorrect as it can get:
> Virtually every other well known development tool in popular use is built upon bloated layers of existing technology, [...] Most developers have just never experienced the sort of self dependent architecture,
Never mind that Red is actually implemented in another abandoned proprietary language[0]!
> Never mind that Red is actually implemented in another abandoned proprietary language[0]!
Github's code breakdown by languages for red/red repo:
* Red 83.8%
* Rebol 15.7%
* C 0.2%
* Visual Basic 0.2%
* Java 0.1%
* Shell 0.0%
Only the compiler is implemented in Rebol, the rest, including the interpreter, the consoles, the GUI system and the whole runtime library are implemented in a mix of Red and Red/System. From top of my head, it's about ~25k LOC for the compiler/toolchain (in Rebol) and ~130k LOC for the REPL and runtime library (in Red and Red/System).
The use of Rebol is only for boostrapping the language. The whole Rebol code part will be dropped after 1.0, and the toolchain rewritten in pure Red.
> The use of Rebol is only for boostrapping the language. The whole Rebol code part will be dropped after 1.0, and the toolchain rewritten in pure Red.
@hjek, as @dockimbel noted, and we have never concealed, Red was bootstrapped using Rebol. Doc's stats break things down pretty well, but there's another point to be made. Red is ~95% Rebol compatible. This is a very important detail, and proved that Red could be used to self host in the future. When the need to self-host becomes important, it can be done relatively easily, and with confidence.
Articles you linked are fairly old, unofficial (that is, don't represent opinions of Red designers and developers) and are written by more-or-less experienced Rebol users. That is, it's hard to talk objectively when you have a tunnel vision accumulated over time. These languages are great, and deserves all the praise they get.
As for shortcomings and limitations, here I can speak only form my experience. If you want an open discussion about it with other developers, consider to visit our community chat [1].
"No dependency" goal - whole toolchain is written from scratch and heavily relies on a native functionality provided by underlying OS. This is cool and ambitious, but there are problems:
* developing a compiler on a par with existing state-of-the-art (e.g. GCC or LLVM) ain't small potatoes. Currently there's no optimization layers, and emitted code might left much to be desired. Perfomance of Red/System IIRC is 2-3 times slower than C (again, without any optimizations). Red is 6-7 slower than C.
* As I said, emitter and linker are written from scratch, and signature of compiled binaries doesn't match common ones, which leads to Red toolchain and compiled applications being flagged by AV vendors as a "generic malware". [2] Language adoption suffers because of that, users are baffled, and vendors don't provide a single clue on how to resolve this issue. It's an uphill battle.
Implementation details:
* Red is its own data format, and structure of this format might be considered as sub-optimal by someone - each value is represented as a boxed structure 4 machine pointers in size. On 32-bit systems that's 128 bits, on 64-bits 256, but can be squeezed down to 160, AFAIK.
* Red/View strives to provide a set of native widgets supported across all OSes, which means that more sophisticated widgets (e.g. tables, Android-like swithes, tree-list) ain't included in the box. That doesn't mean that you can't implement custom version of them - but this process isn't trivial and requires some experience.
* Red is currently limited to 32-bit. As stated in the blog post, 64-bit support will likely come next year, but will require a dedicated rewrite of runtime.
* Compiler and R/S toolchain are written in a closed-source (and officially dead) Rebol2, which is a no-go for FOSS enthusiasts. Self-contained Red toolchain executable relies on Rebol SDK, which requires a paid licence which is not selled anymore - this means that no one can build Red toolchain as the one provided on official website by themselves. This isn't critical, as you can always use code in repository to compile from sources, but, well, there's a fair share of nay-saying here.
User experience:
* Learning curve is steep. Documentation is being worked on, but lefts much to be desired, esp. if you are a programming newbie. We compensate it with strong community presence though.
* Obviosuly, decision to go blockchain generated much controversy and became a major source of gossips. Crypto community is highly polarized: toxic brain-dead speculators on the one side, and extremely smart, dedicated individuals on the other. The former cause us major pains and headaches, the latter keep inspiring us to keep going.
* We also get a lot of harsh critics regarding a pace of development. People go as far as to say that "development is frozen", without considering all the details. Currently there are 12 team members, before that there were 4-5. Rebol never became a mainstream, so it's kinda hard to search for experienced employees, capable of writing production-quality code and contributing to the main development branch.
Your criticism has a point, and I do agree that we need to post more objective, real-world examples in the main blog, and also mention language limitations and short-comings from the designt standpoint.
I also agree that bold claims about Red being easy to pick up are largerly unfounded, albeit serve as a good PR bait.
I've followed Red for a long time, occasionally downloaded builds, and currently hold some of the token.
As of right now I have these thoughts:
* I think the focus on crypto could be a long shot, because my observation is that it's premised on capturing the notoriously fickle dev tools market...
* ...But in the end, Red has to get into a niche and own it and the team is, as some in this thread are suggesting, fanatical enough about what they're doing and confident in its strengths, that they are likely to go farther than anyone else had considered. Which is good enough to make me speculate on it.
* Although Red produces some great demos right now, the lineage of Rebol has its downsides too, since with a lot of these demos, when you get past the trivial and start customizing the UX in fine grain detail, a brick wall of unconventional paradigms is exposed which means that even if I'm experienced in other systems, I start needing a higher level of documentation and handholding. This is not an issue exclusive to Red and frequently impacts software libraries, but one way in which a lot of projects cheat on this problem is to emulate an existing API with lots of adoption and say, "Look, we're the same!" And then they don't have to document, they just steal the existing users.
* Regarding the pace of announcements, there's a rule of thumb Valve worked out for updates of Team Fortress 2 years ago(discussed in one of the articles or talks from then) that I see as more-or-less applicable to all software: Roughly every two months, make a large release with a detailed summary narrative. Project news is a great marketing tool when it's sized like this. Smaller releases tend to not make headlines, larger ones don't have a larger impact. So that's a proposed benchmark for what Red could be doing. The fact that this post blew up is a sign that something is going well, though :)
Thanks for responding politely to my somewhat accusatory comment.
It sounds like Red is driven by a small but very dedicated community, and the way it's both designed and promoted makes me think of TempleOS. Terry Davis' constant eulogies about how his own eccentric OS compares with Linux were obviously delusional (for a start, TempleOS doesn't do networking at all). Similarly comparing Red to Clojure when Red doesn't run on 64-bit machines is also misguided.
However, taken on its own terms TempleOS is an amazing piece of art, and I'm also sure that Red does something new and interesting. Perhaps that style of "PR bait" is just how you roll, but I am certainly glad you took your time to write a more down-to-earth description of the project. Reading that makes it easier for me to appreciate Red as more of an esoteric language that is of great use within its community.
> comparing Red to Clojure when Red doesn't run on 64-bit machines is also misguided
It is misguided, and such comparison wasn't made by any of official representatives, if that's what you imply. I only recall that decision to make a split between Red Foundation and core development team was influenced by Clojure business model, which is backed by Cognitect (correct me if I'm wrong).
Project has ambitious goals and strong, visionary roadmap. Perhaps too strong, as your comparison to TempleOS is slightly worrisome to me ;) Which tells me that current approach to marketing and overall pitching should be reconsidered...
However, I strongly disagree that Red is esoteric, and all technological advances with implemented features up to this point (covered in official blog) serve as a testament to it.
As for small community - risking to sound like a snob, I'll say that Red might not be for everyone, so as any other language - it pick you, not the other way around. Besides, this is still the early days for us, full of ups and downs, challenges and struggles. These things, they take time [1].
Regardless of gender and nationality of community members, and despite the fact that Red is an alpha software, the following projects were created, which may qualify as highly visible:
* neural networks [1]
* computer vision framework [2]
* dataflow engine [3]
* ports of (cross-platform) GUI widgets [4]
* projectional editor [5]
* drawing apps [6]
* operating systems (an in-house project as of now, so no link)
If you don't know what to make out of Red, I'd suggest to grab the latest build [7] with a list of learning resources [8] and do a bit of research. Official About page [9] also gives a good list of main features.
Big libraries indeed aren't necessary, because most of batteries are included in a 1MB executable, and common needs are covered by core library. Full-fledged module system is missing, but is planned for 0.8.0 release. We also have a large Rebol ecosystem, from which various scripts and applications may be ported, if necessary.
[1]: http://redlcv.blogspot.com/2018/11/neural-network-with-red-l...
[2]: https://github.com/ldci/redCV
[3]: https://gitter.im/red/red/gui-branch?at=5c018edb8fa4333e391b...
[4]: https://gitter.im/red/red/gui-branch?at=5c03fdbabe66d8252666...
[5]: https://gitlab.com/rebolek/values
[6]: https://github.com/toomasv/drawing, https://github.com/honix/Redraw
[7]: https://www.red-lang.org/p/download.html
[8]: https://github.com/red/red/wiki/[LINKS]-Learning-resources
[9]: https://www.red-lang.org/p/about.html