I still don't know what to make of this language. If anything, it sounds too easy, making me think "what's the catch?" Is this a small programming cult or is it Czech wizardry obscured by a language barrier? Are there no highly visible Red projects because of shortcomings in the language and its community, or because the language is so potent, its users so empowered, that big libraries aren't necessary?
Rebol and Red are meant to be easy on its surface, while still allowing more complex stuff if you dig deeper. Of course there is a catch - e.g. if you want to modify some GUI element or create one, you need to understand all the underpinnings. On the other hand - dialects are nice way of an interfacing. I don't want to sound bold, but why Java provided its FX, or Qt its QML? Simply because once you are working in certain domain, you don't need complex language constructs.
As for the Czech wizardry, I might put things into some context, myself being Czech, but far from being a wizard :-) It all stems from the Amiga heritage. Remember - Rebol was created by Carl Sassenrath, Amiga OS creator, and Czech community had kind of strong following to it. Red though, is more multinational, but so was Rebol too - maybe Czechs might be more vocal here or there, in terms of the community involvements. And that's just all.
A noted, it's easy to start, but also powerful. Logo was the same. It was most well known for the turtle, but it was really Lisp, and Brian Harvey (Berkeley CS Prof) wrote a great 3-volume series called Computer Science Logo Style.
Red is potent, but also Alpha.
Big libraries are rarely needed. e.g., we have a native image datatype, and codecs for 4 common image formats. No external libs needed. The GUI system is built in, though it added to our size quite a bit. We're over 1MB now.
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].
I also had strong opinions about this at first. Then I thought, better they get some money through this than all the projects out there that are obviously scams. If they have fun with their C3 language and their interfaces to whatever blockchain, good for them, at least they use the money to drive Red forward. Also happy they didn't lose everything with the last crash.
From a language standpoint, it's just a really interesting project.
Understood, so you know there was a reason for branching out into the blockchain space, as there's a real need for better langs there, and less competition, which leads to more visibility in an area that his hot technology. For the project to survive, we'll have to try a lot of things.
> * Apparently, it took it 8 years to get simple (in words of author) G.C. [3]
Apparently you didn't look close enough at the history and are making up fake information.
Preliminary work on GC started in 2017 for a month, then resumed in 2018 for about 3-4 months. So in total, about 4-5 months, mostly spent on adjusting the runtime library and tracking notoriously hard to catch GC-related issues.
Hey there, I did not intend to imply it took that long in actual development time, more in the sense that the g.c. feature did not exist in He language for that long, for different reasons (evidently it wasn’t a priority).
A dynamic language without g.c. sounds dangerous to use. I’m just surprised it wasn’t a priority for so long.
There are a lot of topics here now, which is great, and the opening question about what to make of Red is a good one. The problem in answering it is the same problem we have when pitching it to people: it's hard to sum up.
Is there a catch? Yes. More than one actually. One is that, because we are building things from the ground up, we don't get things for free that other languages do. For example, JVM-based langs get a lot for free, but at a cost. Another catch, and a big one, is that Red is fundamentally different in some design aspects, both superficial (syntax) and deep (all is data, words and bindings, etc.). Those two things deter a lot of people. We get that. If you want to keep doing things mostly the way you always have, Red is not for you. If you just want lots of familiar libs and features, you may have to wait for them, or help build them. This makes us a self-selecting community. We don't want to be a cult, but we also won't compromise certain things with the hope of it making us more popular. There are few easy choices here.
For those who find Red, and give it a shot, not all will like it, and not all who like it will understand it or use it effectively. We also accept that. For those who have the courage to try something new (I mean, really try it), and who take the time to understand it (the process of which brings its own benefits, no matter what language you use), and who reach the moment where it clicks in their head, there is no going back.
Whether you support and commend features, or criticize them fairly, they are features. To have meaningful discourse about Red, we need to go deeper. Much deeper. If you only want to compare Red to other tools, on their terms, we'll often lose. But if you look at what Red can do, that they can't, and Red's fundamental goals, it becomes clear that comparisons don't mean much. That's true for any 2 languages. It can help, provide context, etc., but ultimately you have to evaluate a language or tool on its own merits, just as you have to evaluate yourself and see your own worth and value without comparison to others.
If you think the state of software development is just fine, and a few tweaks are all we need, Red probably isn't for you. But if you have nagging doubts about why things are so hard, so big, so complex, when it seems like they should be easy, small, and simple...maybe you'll be curious and brave enough to take the Red pill. Most, we know, just want the big juicy steak.
We can talk more, explain more, if people want. Gitter is our most active channel, but we can try to respond here as well. We're glad to hear what people like, and accept fair criticism.
> One is that, because we are building things from the ground up, we don't get things for free that other languages do. For example, JVM-based langs get a lot for free, but at a cost.
Red is implemented in Rebol2. That also comes at a cost due to Rebol2 not being free/libre and being abandoned.
> But that was a very important choice. Do you understand why?
I'm sure you have your reasons for doing so, and I'm glad that it's working well for you.
I'm not having a go at you for making Red run on Rebol. But I am having a go at you for having a go at Clojure for running on the JVM, while claiming that Red is built "from the ground up".
All this posting about how Red is better than all other languages, and that people, who use those other ones, are stuck in their ways or not smart enough, and defensively lashing out at people who point out limitations of Red, it just comes across as megalomaniacal. Being implemented in Rebol2 apparently also "has a cost" for Red, namely that Rebol2 is abandoned, and that there's no 64-bit support, and that a otherwise free/libre programming language has non-free dependencies, and you might be in a pickle if you want to include newer versions of libraries that are presumably statically compiled into the Rebol2 binary blob, especially your SSL library... but apparently, from what I read about Rebol[0], it's only the "pro" version of Rebol that has SSL-support, so what about Red?
Do you understand those issues? It's too hand-wavy to say that I'm not looking at Red "on its own terms", especially because those terms include being a "good fit for any task!"[1]
Can you back up your acqusations with palpable evidence? Neither Red author, nor any of official project representatives "made a go" on Clojure or any other language and its community, as far as I'm concerned.
As for "defensive lashing" - you should make a distinction between informed, well-posed critique and arrogant, unbacked ranting. Everyone accepts the former and does not tolerate the latter - the team is no exception. And, again - either provide an evidence for what you say or back off your claims. Calling project megalomaniacal for fighting FUD is completely off base, and every criticism raised in this thread was handled politely. Heck, I can pull out any blog post from one of Clojure community members and start claiming that it represents opinions of Hickey. Would that be OK? I guess not.
Even if there is a cost in using Rebol2 as bootsrapping language, it will be gone with 1.0 release. And right now Rebol source code takes roughly a quarter of whole codebase (compilers and linkers for Red and Red/System) - the rest is pure Red and its dialects. So your whole paragraph is completely irrelevant and misleading: lack of 64-bit support has nothing to do with Rebol2, bold "non-free dependency" claim does not have any weight to it (since when bootstrapping language is a dependency?) and "SSL library" passage tells me that you don't have an idea of what you're talking about.
And use official resources (Red and Rebol websites) as references, would you? Wiki page is an extremely weak testimony to whatever you have to say.
No project is ideal, but Red's terms are completely different from what you try to impose here. I do not say that we don't have holes in the housing - we do, and we have all what is necessary to close them.
> And use official resources (Red and Rebol websites) as references, would you? Wiki page is an extremely weak testimony to whatever you have to say.
That's my mistake. The quote about Clojure I provided were from `redprogramming.com` which is linked to from the official website and from your Github, so it looked official to me.
The comparison with Python is from a blog of one of the Rebol developers. Not sure whether that qualifies as official.
If the Wikipedia article about Red is wrong, it might be a good idea to correct it..?
> Even if there is a cost in using Rebol2 as bootsrapping language, it will be gone with 1.0 release. [...] (since when bootstrapping language is a dependency?)
That's cool, and I wasn't aware of that. I just assumed Red was to Rebol what Hy is to Python and Clojure to Java, but that's great that that is a non-issue!
> `redprogramming.com` which is linked to from the official website
Official page links to learning resources provided by community, to compensate for TBD state of official documentation. We can't, however, control other people's opinions, or dictate them how to express themselves.
People can unintentionally say provocative things in a burst of excitement, I hope you understand that. And there are reasons to be excited about Red and Rebol.
> The comparison with Python is from a blog of one of the Rebol developers. Not sure whether that qualifies as official.
As I said, we can't control other people, and are not responsible for other's bold claims. I too do not think that this benchmark was fair and objective. As for the wiki page - we'll note that. I'm just saying that any other person can go there and apply his/her edits, without project's consent.
> I just assumed Red was to Rebol what Hy is to Python and Clojure to Java, but that's great that that is a non-issue!
It's good that this confusion is resolved. Hy and Clojure are hosted languages by nature, but Red is entirely self-contained (although you might think that it depends on Red/System dialect).
As has been noted by others, we have never "had a go" at Clojure. Language designers and the people who build them have our respect, even if our choices differ. If we criticize them (and we do at times, being human, and thinking we're right ;^), we try to be fair. Rich Hickey's talks are some of my favorite to watch, and I have nothing but respect and admiration for him.
Of course everything has a cost, but to call us megalomaniacs is a bit harsh.
You didn't say you understood the reason, but I pointed it out in another reply here. By bootstrapping from Rebol, and being 95% Rebol compatible, we proved that Red could self host, and also leverage almost all the existing code when we get to that point.
To ask if we understand those issues comes across as insulting. Sure, we could be tech smart but miss obvious things, but that one we know about. ;^)
The Red Language has always described itself as functional imperative. I used to point out to people that functional programming can be imperative and nobody (I do mean nobody I spoke to about this) would believe me on this. Then I would point out to people Red Language as an example and they would scratch their heads in confusion.
Functional imperative is the idea of using functions to define the shape of an application, which is to say the nesting of functions defines both the stacked structure and the resulting control flow opposed to describing units of logic or any sort of reflection.
Idiomatically written Red is largerly data-driven, composed out of mini languages and micro formats (dialects), with huge emphasis on homoiconicity and rich set of available datatypes.
Functions indeed are mostly used to guide the flow of program and stack dialects on top of one another, so the resulting app is like a dedicated toolchain (or even a VM), where each component is a small interpreter or compiler.
> I used to point out to people that functional programming can be imperative and nobody (I do mean nobody I spoke to about this) would believe me on this.
Interesting. Monadic Haskell can be quite imperative if you want it to be, as can SML or OCaml. Scheme and Lisp have imperative parts too.
I was so worried when they announced their cryptocurrency plans that Red wouldn't survive when the cryptocurrency hype bubble would inevitably pop. Glad to see that they managed.
Although Logo is said to be an ancestor to Rebol (which in turn is an ancestor to Red), there's more it than an apparent "childish" simplicity on the surface.
Language that hits the sweet spot between Forth and Lisp might be a good fit for some kids, but its scope is way outside of mere scripting and toying, and demands a respective approach - something that only grown-up engineers can fully appreciate. YMMW.
> its scope is way outside of mere scripting and toying, and demands a respective approach
Maybe I misunderstand where you are coming from, but to me this appears similar to saying that using acrylic paint demands a respective approach because the great paintings of the last century were made with it.
To which I would say: no, not really. Acrylic paint only demands a respective approach in the sense that it may be toxic and you don't want kids to finger paint or risk swallowing it. But people can paint whatever they want with it.
Similarly, Red demands a respective approach because it's powerful enough to shoot yourself in the foot (oops, some kid deleted half of the files on the SSD by accident). Maybe that is what you meant with "scope", but it's not what I made out of it upon first reading.
Besides, the solution for that is simple enough: make a child-safe dialect.
My point is that Rebol and Red are extremely good chameleons - they hide all their power behind the approachable facade, and make a false impression of "oh it's just X, nothing serious". I saw a fair share of people who, based on that first impression, dismiss Red as a quirky alternative to Python, or a GUI-building kit, or a pretentious academical toy, you name it.
But that doesn't mean that these languages child-safe by default, and indeed, foot-shooting starts as soon as you begin to harness that power - that's where the real fun is, which IMO kids can't appreciate fully. As you said, it's anything but a finger paint.
But if it clicks in kid's brain from the get-go and grows over him, then the world is ought to see some great paintings ;)
Ah, so we were more or less on the same page from the beginning.
BTW, is there a child-safe dialect for Red? How easy or hard would it be to create an environment like Processing or p5.js, without the foot-shooting risks?
Creating a dialect is pretty easy, though it's a broad term, so not ALL are easy to create. :^) An environment is an entirely different beast, but @9214 addressed that already as well. The more you leverage core features, the more you get outside your dialect though. You trade power for safety. It's easy to create a simple Logo Turtle interpreter though.
Easy - you can create a live-coding IDE in 20 lines or so, Draw and View a pretty capable for interactive Processing-like demos, bottlenecks can be rewritten in R/S.
Hard - hit the academical papers and define what can be considered a "child-safe programming environment". Then implement a separate toolchain for that.
[Somewhere between Easy and Hard?] - make the dialect operate in a safe sandbox that can't destroy your computer
... plus optionally convenience functions fitting for the creative problem domain like how Processing removes a lot of Java boilerplate, and p5 does similar things for using the various JS APIs. One can just look at the APIs of Processing, p5 and OpenFrameworks to get an idea of what works there, though.
Safe sandbox: Rebol had Protect and Secure dialects [1, 2], which are planned to be implemented in Red. Language is very dynamic though, so there's a certain limit on what kind of safety can be enforced at runtime.
Creative problem domain: that's what Red is all about in my point of view - slapping domain-specific languages one on top of another to pin down the exact problem space. Draw for 2d vector drawing, View for GUIs, Parse for, well, parsing and metaprogramming, et cetera. The crux is usage of same data format and common notation at every abstraction layer, be it low-level programming or high-level scripting.
I don't think that Red can handle large-scale projects the way language workbenches do (yet), but it can be used for moderately small embedded DSLs.
It is "amazingly simple to get started" but also amazingly difficult to go much deeper. Some of this, imo, is because the preferred introduction to Red/Rebol is commonly the view (GUI) subsystem. Gradual documentation or other structured paths to the deeper end of Red/Rebol appears to be non-existent.
I've seen Red compared to Lisp, Smalltalk, and Forth and other concise languages.
Anyway, the road to Red/Rebol deep mastery is heavily shrouded at present. All that said, the Red project is amazing and pretty much unique in ambition and I, for one, am certainly hoping it makes it through to a solid 1.0. At that point, I hope, strong effort will allow the language to be fully grokked by, at least, the folks who are comfortable with the likes of Lisp and Haskell.
Let's keep our fingers crossed and support the 2019 roadmap.
Here [1]. Red and Smalltalk syntax look similar, but semantics are very different. They only relation to object-oriented languages Red / Rebol have is through prototype-based OOP, e.g. Self [2].
Forth doesn't have any grammar specification AFAIK - any space-separated string of ASCII tokens is a valid Forth program, but it may vary from dialect to dialect. It's more of an idea than programming language.
It is good to see there IS a specification; I - and I think some others (see the Temple OS comments) - had concern Red/Rebol might actually be too ad hoc (throw things against the wall and see if they stick).
Is there means to access the lexer directly as a means to explicate how, exactly, Red is interpreting? The use of blocks in Red, and the layout in general, did remind me of Smalltalk but in Smalltalk I could at least rely on really simple syntax rules including some really useful grouping tools to break things up into more human friendly chunks (parens; semicolon; and period).
The spec says "*
As a first operation of the toolchain, the text file will be subjected to lexical analysis which will break the text up in a series of lexemes, i.e. textual representations of Red single values, interspersed with grouping tokens. The grouping tokens should occur in properly nested pairs, and are the following: ( ), [ ], #( ), #[ ]. A sequence of lexemes enclosed in matching grouping tokens represents a Red grouped value of a certain type, and this construct may again be enclosed in grouping tokens etc. Note that the token pairs " ", #" ", { }, #{ } and < > each delimit a single value, they are not grouping tokens...As a rule, lexemes must be separated from each other and from grouping tokens by one or more whitespace characters.*"
Anyway, I think trivial access to the lexer output, so one might SEE exactly how the Red interpreter is viewing things, would go a long way toward dispelling the "Temple OS" concern and providing that on-ramp that IMO is otherwise missing.
No offence, but very few people who raise such concerns actually take time to learn the language (or even launch a REPL at least once) and understand its design, so I appreciate you digging deeper. "Things are thrown against the wall" only in terms of constant search for a sound business model, and this, I believe, is the struggle that any startup (esp. programming languages) faces.
> Is there means to access the lexer directly as a means to explicate how, exactly, Red is interpreting?
I think you can start by, well, reading lexer code, which is written in Parse dialect [1], but specification I showed you might be more approachable. But really, just grab the latest build and start playing, I'll give some very basic examples below.
Now, to the main point: from what I know, Rebol (and Red) are based on research in denotational semantics that Carl Sassenrath did. I'll try to briefly explain the main points.
As you already know, everything starts with a UTF-8 encoded string. Each valid token in this string is converted to an internal data representation - a boxed structure, called a value slot or sometimes a cell.
Value slot is composed of a header and a payload. Header contains various flags and datatype ID, payload specifies exact content of the value. If content doesn't fit in one value slot, then payload contains a pointer to an external buffer (an array of value slots, bytes, or other units + offset and start/end addresses IIRC) with extra data.
So, lexer converts string representation to a tree of value slots (this phase is called "loading"), which is essentially a concrete syntax tree (CST) - this is the crux of homoiconicity.
Everything is a (first-class) value, and every value has a datatype (we have roughly 50 of them right now). And there's no code - only this data structure, which is just a block, which you can freely manipulate at will (so as any other value).
What interpreter does is just a "walk" over this tree of values, dictated by a set of simple evaluation rules (expressions are evaluated left to right, operators take precedence over functions and have a more tight left side, literals evaluate to themselves, functions are applied to a fixed set of arguments, symbolic values of type "set-word!" [more on this later] are bound to the result of expression that follows them, etc) but there are a couple of catches.
The first catch is that some values are symbolic - that is, they indirectly refer to some other values via a context (namespace). You can modify this reference (called binding) freely at runtime, and thus change the meaning of symbolic values and of an entire block that contains them.
So, the "meaning" of a given block is always relative to some context(s) - this is what relative expression means (RE in REBOL). And context itself is just an environment of key/value pairs (key is a "symbol", value is its "meaning") represented as an object (O in REBOL).
>> block: [6 * 7] ; "block:" is a value of type "set-word!"
== [6 * 7]
>> type? second block
== word! ; words are one of the symbolic values I've mentioned
>> do block
== 42
>> bind block object [*: :+] ; now "multiplication" means "addition"
== [6 * 7]
>> do block
== 13
The second catch is that you are not restricted by default interpreter (represented by "do" function) and can use any other one or even implement your own, thus making an embedded DSL - a dialect in Red/Rebol parlance.
* Red/System takes a block of C-level code and does the prescribed job.
* View takes a block that specifies GUI layout and shows a fancy window.
* Draw takes a block of drawing commands and renders an image.
* Parse takes an input series and a block of PEG grammar, and parses the input.
* Math takes a block and interprets it with common operator precedence rules.
Sky is the limit, and its dialects all the way down.
To reiterate: the basic building block (no pun intended) is a block of values, which can represent either code (relative expression which, upon evaluation, will yield a value) or data (just a bunch of values arranged in a specific format - such micro-formats are considered to be dialects too †). Block can also contain symbolic values (called words) which can change their binding during evaluation, and thus alter the semantics of expression.
There's a lot hiding behind the facade, as you can see. And what is there is hardly an ad-hoc hodge-podge slapped together.
(†): one example of such micro-format dialect is function specification, e.g.
spec: [
"Add two numeric values together"
x [number!]
y [number!]
]
is a specification (or an "interace") for a function that performs addition. Here's a block that expresses addition of two specific numbers:
[1 + 2]
If we wish to abstract over it, we can substitute 1 and 2 for words:
expression: [x + y]
And then we can alter bindings of these words to actual arguments we wish to add together:
bind expression object [x: 1 y: 2]
We then can evaluate such expression and yield a resulting value:
== do expression
>> 3
The trick is that functions are just abstraction over evaluation of expression in some environment, that is, a syntax sugar for
do bind [...] object [...]
with some additional optimizations and type-checking. So, addition instead can be expressed as:
>> add: func spec expression
== func [
"Add two numeric values together"
x [number!] y [number!]
][x + y]
>> type? :add ; ":add" is a value of type "get-word!" which, on evaluation, yields function's value referred by word "add" as-is, without triggering its application.
== function!
>> add 1 2
== 3
Thank you for the details; I will study them more.
But let me try again with my main question. I want to see what the lexer outputs. How can I view that?
I'd like to be able to hand a string (or file) of what I think is valid (or invalid) Red code and have the lexer return to me that input NOT executed but parsed into lexemes, grouping tokens, and appropriate white space.
Again, according to the specification you linked, the lexing is a discrete step to resolve any ambiguity of syntax in this manner ahead of interpretation/execution. So I'd think accessing the lex output would be trivial and transparent -- not to mention invaluable for learning and debugging Red. Why should lexer be crystal clear about exactly what is going to be interpreted, and in what order, while the human is sometimes left in the dark?
Then, obviously, I'd like to be able to pass this lexed and "grouped" string directly in to the interpreter for execution as a second step. Showing me the result of interpreting a string isn't nearly so helpful as this would be. Can this be done?
Why would I want to do this? Well, I've weird. ;-/ More seriously, at this point you guys don't have a good stepping debugger - it would help me debug my own code. It would also be a rather cool thing to be able to do just for the hell of it, as a great exploratory exercise. I would think I could then play with the lexemes individually once I can see exactly what the lexer sees instead of only what I think - too often mistakenly - the lexer sees.
> I'd like to be able to hand a string (or file) of what I think is valid (or invalid) Red code and have the lexer return to me that input NOT executed but parsed into lexemes, grouping tokens, and appropriate white space.
This is what "load" essentially does - it takes a string and returns a concrete syntax tree [1]. "do" then takes that CST and evaluates it. You can do that in a single-step manner with "do/next" (there's also "load/next"). Moreso, you can think of blocks as phrase markers (see wiki example):
[S [NP John] [VP [V hit] [NP the [N ball]]]]
Now compare it to Red internal data structure written down in similar fashion:
<block! [<integer! 1> <word! +> <integer! 2>]>
Here I loosely follow phrase marker notation - nonterminals correspond to datatypes, terminals correspond to literal values. But datatype is implied by literal form, and implicitly contained in each value slot (its a datatype ID tag in the header), so I can tidy this up to:
[1 + 2]
This is what lexer returns - just a block. You can then manipulate it whichever way you want and evaluate.
> at this point you guys don't have a good stepping debugger
We don't have it for a reason - implementing it in user-space would be extremely limited as you can't really distinguish between code and data, and so can't adequately place debugging hooks. The best alternative is just to spruce up block with debugging "print"s and such, or, in case of syntactic errors use "load/trap" and search for error values. Rebol had some interesting projects in this regard, e.g. Anamonitor comes to mind [2]. I think someone already ported it to Red, or re-implemented using our reactive framework.
There was a recent discussion in community chat about that, and we came to conclusion that debugger should rather be implemented at the level of "load" and "do" themselves (e.g. "load" can provide some metainfo, like line numbers and file name, "do" then can single-step it in real time and provide the meaningful info).
A great feature of Red is their cross platform GUI support. I see Android is also supported. Does anyone know what the status of iphone (iOS) support is ?
I wouldn't call its GUI really cross-platform yet. Linux GUI definitely isn't production ready. Android is somewhat usable. iOS is not working.
Nevertheless, I keep my fingers crossed. My estimate is in 2-3 years you will be able to start writing small cross-platform GUI apps in RED and not worry about trifle problems.
One major stumble block in GTK backend development is a monstrocious string-oriented API for setting widget properties. There's a more low-level one, but it's depricated.
FYI, development of backend happens as we speak [1].
This came up not long ago, and we have to define "cross platform" to say whether Red meets the criteria. Red does have a cross platform GUI system, though it is only fully implemented on MacOS and Windows currently. We don't run on iOS at all yet. What the current system shows is that a single, cross platform dialect can abstract away the native OS APIs in a clean way, though there will always be tradeoffs, as every OS has different features.
The RED Wallet is an example of a cross platform app, done today.
A language with a GC does not seem appropriate for a "full-stack" language with which one would write operating systems, drivers, or game engines. I don't know why any language without full manual memory management would ever posit itself as being appropriate for these domains. It's naive at best.
You are right that GC s not good fit for low level programming, but Red solves this problem with dialects (DSL) of Red. For low-level it uses Red/System [1], which is C-like language with Red syntax. There are also other dialects (DSLs) for other areas like GUI, parsing, etc... It's better approach IMO than trying to solve everything with one language.
This was something that definitely got my attention.
If the butthurtness of 9214 above is representative of the community, though, I'd probably last 10 minutes in their forum before being banned for life.
Even though some of my responses in this thread can be considered butthurt-ish in the hindsight, I don't think that judging whole community by one individual is a good idea.
- Modula-3 at Olivetti DEC/Compaq/HP and University of Washington
- Oberon, Oberon-2, Active Oberon, Oberon-07 at ETHZ
- Oberon-07 at Astrobe
- Component Pascal at Oberon microsystems AG
- Sing#, Dafny and System C# (M#) at Microsoft Research
- Java when running AOT compiled on bare metal embedded systems like PTC Perc and Aicas Jamaica
- D by Digital Mars
- Go at Google (Fuchsia) and MIT (Biscuit)
If we don't have a mainstream OS written in one, it is mostly a consequence of politics and willingness to push it forward, instead of doing yet another UNIX clone.
Fuchsia's TCP/IP stack and file system management tooling are written in Go.
D is a project for a systems programming language with GC enabled by default. There a couple of experimental OSes like PowerNex.
RocksDB is not part of the Cassandra project, as far as I can tell.
Anyway it doesn't matter how niche they are, rather they were successful implemented and aren't mainstream as a consequence of politics and willingness to push it forward.
Doing UNIX clones is cheaper than improving the overall security.
Which is why in spite of the ergonic issues of using the NDK as it is, I enjoy the fact that Google makes it quite hard to use C and C++ instead of Java/Kotlin on Android.
Which on their little brother variant, Android Things, is even more explicit with user space drivers being written in Java.
Then we have Apple pushing Swift, which even if it takes another decade, it will eventually make Objective-C join Carbon.
Modern systems programming seems to be the land of luddites in IT.
I write kernel drivers and firmware code mainly in C and a little bit of assembler.
I agree with you pretty much.
That said, it's healthy to have some people exploring alternative paths. Maybe some of that exploration will be fruitful, way or another.
Especially firmware development is somewhat ossified to C. C is universally supported and a lot of people in this trade don't even see need for a change, despite vastly increased system complexity and exposure over open networks. It's not enough for the things to just to work — they need to work securely, otherwise ultimately our infrastructure is at risk.
C can work with 16 bytes to 16 TB+ (or a lot more) of RAM. It can span from a 4-bit single core microcontrollers to massive RDMA supercomputing clusters. C contender does not need to cover all of that, but should keep that enormous range in mind.
The contender should also be able to interface with C library and linking interfaces. Otherwise it's hard to compose working systems. No matter how amazing the new language is, you can't build everything from scratch.
So far I've placed my biggest hopes in Rust. But we'll see how the things evolve. One should keep an open mind. I wish good luck for the Red folks.
By the way, you often can't allocate or free memory in firmware or kernel drivers either. Like in a kernel IRQ handler or on an embedded device with hard realtime and stability requirements. In that kind of case GC or manual allocation would not make much difference at all — you'd only allocate at initialization or at teardown.
>That said, it's healthy to have some people exploring alternative paths. Maybe some of that exploration will be fruitful, way or another.
Exactly. Perhaps it is not appropriate to write production ready drivers and operating systems that people will use today in a GC language; but in the future that could change and change will only happen if people take the time to experiment.
C doesn't even assume that code and memory live in the same address space! The portability of standard C is almost as breathtaking as the ease with which you can introduce undefined behavior.
"Full stack" means different things to different people. There are plenty of GC languages which are still relatively-high performance and can thus be used for technically-challenging, "system"-like tasks. In fact, this very variety is what makes it a bit hard to figure out what Red's unique selling point might be, although it's easier if you're familiar with its predecessor Rebol.
> There are plenty of GC languages which are still relatively-high performance and can thus be used for technically-challenging, "system"-like tasks
Unfortunately, they frequently lack the other attribute which makes C and C++ such pervasive solutions, namely portability.
Having "theoretical portability" (for example JVM bytecode) is not much use if your target hardware or operating system cannot support a JVM without you having to first port the JVM yourself.
Generally agreed, although the huge number of bugs out there that are attributable to manual memory management suggests that other solutions are worth looking for. Perhaps Rust is heading in the right direction.
Minecraft Java Edition is 100% Java, but it's also notoriously slow, and experiences lag spikes, which are often attributed to garbage collection. I think an OS written in a GC language can certainly have adequate latency and throughput, but I don't think Minecraft is a good example of that.
Your comment itself is extremely naive and misinformed. Red toolchain relies on Red/System DSL, which is a C-level language with manual memory management.
