Comment by 9214 | Hacker News Reader

Comment by 9214 | Hacker News Reader

Parent Full thread

> 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

Time will tell.

[1]: https://www.red-lang.org/2018/01/overview-of-red-development...

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

> this is provably false

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.

> If it's provably false, then take your time to actually prove it before calling someone a liar.

1. It was your claim that it was "just formatting changes". Which they are not

2. This doesn't explain why 99% of bug fixes contain no tests

> If it's provably false, then take your time to actually prove it before calling someone a liar.

Testing and comments in code are not high standards. They are basic development hygiene.

> Absolute nonsense. Read the changelogs, roadmap and Github releases before making such claims.

I've read them, that's why I'm making such claims.

Releases: https://github.com/red/red/releases

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.

I very much doubt it was 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.

Reply on news.ycombinator.com