3 ms·

> 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

by 9214 8y ago

> 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-history.html https://www.red-lang.org/2018/01/overview-of-red-development...

dmitriid 8y ago
> 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?
- 9214 8y ago
  > 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.
  - dmitriid 8y ago
    > 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 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.

by 9214 8y ago

dmitriid 8y ago

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

9214 8y ago
> 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.
- dmitriid 8y ago
  > 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 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.