Live data from Hacker News

Red Programming Language: Plans for 2019

red-lang.org

131–140 of 141 posts

Re: Red Programming Language: Plans for 2019

#131
post #126

Earlier quoted context omitted.

> (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.

Sorry about that. Looked official to me and was linked to from the Red page and from your Github, but sorry about the mistake. s/creators/community/

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.

Re: Red Programming Language: Plans for 2019

#132

Things I find exciting about Red: * Small * Lisp like * Cross compiler "done right" [1] * Red/System is a cool concept (a language dialect for low-level/systems programming). Things I find discouraging: * Bus factor = 2 (IMHO) [2] * Apparently, it took it 8 years to get simple (in words of author) G.C. [3] * Docs and example code are not great, lack of existing apps (chicken & egg problem). 1: https://github.com/red/…

> * 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.

Re: Red Programming Language: Plans for 2019

#133

Things I find exciting about Red: * Small * Lisp like * Cross compiler "done right" [1] * Red/System is a cool concept (a language dialect for low-level/systems programming). Things I find discouraging: * Bus factor = 2 (IMHO) [2] * Apparently, it took it 8 years to get simple (in words of author) G.C. [3] * Docs and example code are not great, lack of existing apps (chicken & egg problem). 1: https://github.com/red/…

> * 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.

Re: Red Programming Language: Plans for 2019

#134
post #54

Earlier quoted context omitted.

> > 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…

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 lookin…

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.

[1] http://lambda-the-ultimate.org/node/1240#comment-48582

[2] https://github.com/red/red/issues/3692

[3] https://github.com/red/red/issues/3713

[4] https://github.com/red/red/issues?q=is%3Aissue+is%3Aclosed+l...

[5] https://github.com/red/red/issues?q=is%3Aissue+is%3Aclosed+l...

[6] https://github.com/red/red/blob/master/tests/source/units/re...

[7] https://twitter.com/dmitriid

[8] https://pastebin.com/jezLyDVt

Re: Red Programming Language: Plans for 2019

#135
post #54

Earlier quoted context omitted.

> > 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…

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 lookin…

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.

[1] https://gist.github.com/dockimbel/2af078e02e56fcc092aea771de...

Re: Red Programming Language: Plans for 2019

#136
post #63

Earlier quoted context omitted.

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.

> Regarding development: I'd appreciate if you elaborate over your critique. There's nothing to elaborate, really. If you list all "status.tested" issues, how many are tested? Let's take the top few as of today. 1. Malignant output from react/link, https://github.com/red/red/issues/3713 fix: https://github.com/red/red/commit/644be4b1e3bfcf70a5f9f5e006... One-line fix, sure. Where's the test? 2. new-line flags are not…

> Almost all issues are fixed by the same two people who develop Red.

Let's look at the reality by taking all the fix commits (prefixed with "FIX:") on red/red repo in the last 6 months and grouping them by author:

    qtxie        : 97
    dockimbel    : 39
    bitbegin     : 21
    endo64       : 6
    Rudolf       : 6
    Toomas       : 4
    greggirwin   : 3
    semseddin    : 3
    FLuX LoOP    : 2
    Vladimir     : 2
    x8x          : 2
    PeterWAWood  : 1
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?

[1] https://doc.red-lang.org/en/reactivity.html

[2] https://github.com/red/red/blob/master/environment/natives.r...

Re: Red Programming Language: Plans for 2019

#137
post #63

Earlier quoted context omitted.

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.

> Regarding development: I'd appreciate if you elaborate over your critique. There's nothing to elaborate, really. If you list all "status.tested" issues, how many are tested? Let's take the top few as of today. 1. Malignant output from react/link, https://github.com/red/red/issues/3713 fix: https://github.com/red/red/commit/644be4b1e3bfcf70a5f9f5e006... One-line fix, sure. Where's the test? 2. new-line flags are not…

> 1. Malignant output from react/link, https://github.com/red/red/issues/3713 > One-line fix, sure. Where's the test?

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.

> 2. new-line flags are not cleared on subsequent calls, https://github.com/red/red/issues/3707 > Severl line-fix. Where's the test?

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]

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

[2] https://github.com/red/red/blob/master/tests/source/units/se...

[3] https://github.com/red/red/tree/master/modules/view/backends...

[4] https://github.com/red/red/tree/master/tests/source/view

Re: Red Programming Language: Plans for 2019

#138

Earlier quoted context omitted.

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 lookin…

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, t…

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

I doubt that.

Re: Red Programming Language: Plans for 2019

#139

Earlier quoted context omitted.

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 lookin…

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 yo…

> 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.

A real class act you are.

Re: Red Programming Language: Plans for 2019

#140

Earlier quoted context omitted.

> Regarding development: I'd appreciate if you elaborate over your critique. There's nothing to elaborate, really. If you list all "status.tested" issues, how many are tested? Let's take the top few as of today. 1. Malignant output from react/link, https://github.com/red/red/issues/3713 fix: https://github.com/red/red/commit/644be4b1e3bfcf70a5f9f5e006... One-line fix, sure. Where's the test? 2. new-line flags are not…

> Almost all issues are fixed by the same two people who develop Red. Let's look at the reality by taking all the fix commits (prefixed with "FIX:") on red/red repo in the last 6 months and grouping them by author: qtxie : 97 dockimbel : 39 bitbegin : 21 endo64 : 6 Rudolf : 6 Toomas : 4 greggirwin : 3 semseddin : 3 FLuX LoOP : 2 Vladimir : 2 x8x : 2 PeterWAWood : 1 qtxie and dockimbel are the two main contributors to…

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.

Post reply on HN