9 ms·

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

by hjek 8y ago

> > 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. Edit: More over-the-top praise.[5][6][7][8] [0]: http://blog.hostilefork.com/rebol-vs-python-performance/ http://blog.hostilefork.com/rebol-vs-python-performance/ [1]: http://redprogramming.com/Why%20Rebol%20and%20Red.html http://redprogramming.com/Why%20Rebol%20and%20Red.html [2]: https://www.sqlite.org/fasterthanfs.html https://www.sqlite.org/fasterthanfs.html [3]: https://www.sqlite.org/whentouse.html https://www.sqlite.org/whentouse.html (See the section Situations Where A Client/Server RDBMS May Work Better) [4]: https://news.ycombinator.com/item?id=18844770 https://news.ycombinator.com/item?id=18844770 [5]: https://news.ycombinator.com/item?id=18844002 https://news.ycombinator.com/item?id=18844002 [6]: https://news.ycombinator.com/item?id=18844185 https://news.ycombinator.com/item?id=18844185 [7]: https://news.ycombinator.com/item?id=18844746 https://news.ycombinator.com/item?id=18844746 [8]: https://news.ycombinator.com/item?id=18845102 https://news.ycombinator.com/item?id=18845102

dmitriid 8y ago
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. etc. etc. https://github.com/red/red/issues?q=is%3Aissue+is%3Aclosed+label%3Astatus.tested https://github.com/red/red/issues?q=is%3Aissue+is%3Aclosed+l...
- 9214 8y ago
  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.
  - dmitriid 8y ago
    > 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 https://github.com/red/red/issues/3713 fix: https://github.com/red/red/commit/644be4b1e3bfcf70a5f9f5e0066fdd2cc964cd73 https://github.com/red/red/commit/644be4b1e3bfcf70a5f9f5e006... One-line fix, sure. Where's the test? 2. new-line flags are not cleared on subsequent calls, https://github.com/red/red/issues/3707 https://github.com/red/red/issues/3707 Fix: https://github.com/red/red/commit/b7ee2846b58a1328d57002b3ed2d076d65ca4b7e https://github.com/red/red/commit/b7ee2846b58a1328d57002b3ed... Severl line-fix. Where's the test? 3. stack overflow on limited append/insert, https://github.com/red/red/issues/3705 https://github.com/red/red/issues/3705 The fix contains a single test even though the issue provided three different failure modes: https://github.com/red/red/commit/bd41d35ee5a73cd5779647b50376b0d757c9e8a0 https://github.com/red/red/commit/bd41d35ee5a73cd5779647b503... 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? Too bad the file where the issue is fixed is this: https://github.com/red/red/blob/644be4b1e3bfcf70a5f9f5e0066fdd2cc964cd73/environment/reactivity.red https://github.com/red/red/blob/644be4b1e3bfcf70a5f9f5e0066f... 336 lines of no significant comments other than trivia for the author himself. "New line flags not cleared" whose fix is just a few lines? Oh, it's in a 3000-line file with no comments, https://github.com/red/red/blob/b7ee2846b58a1328d57002b3ed2d076d65ca4b7e/runtime/natives.reds https://github.com/red/red/blob/b7ee2846b58a1328d57002b3ed2d... And so on and so forth. 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"? ----

by hjek 8y ago

dmitriid 8y ago

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. etc. etc. https://github.com/red/red/issues?q=is%3Aissue+is%3Aclosed+label%3Astatus.tested https://github.com/red/red/issues?q=is%3Aissue+is%3Aclosed+l...

9214 8y ago
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.
- dmitriid 8y ago
  > 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 https://github.com/red/red/issues/3713 fix: https://github.com/red/red/commit/644be4b1e3bfcf70a5f9f5e0066fdd2cc964cd73 https://github.com/red/red/commit/644be4b1e3bfcf70a5f9f5e006... One-line fix, sure. Where's the test? 2. new-line flags are not cleared on subsequent calls, https://github.com/red/red/issues/3707 https://github.com/red/red/issues/3707 Fix: https://github.com/red/red/commit/b7ee2846b58a1328d57002b3ed2d076d65ca4b7e https://github.com/red/red/commit/b7ee2846b58a1328d57002b3ed... Severl line-fix. Where's the test? 3. stack overflow on limited append/insert, https://github.com/red/red/issues/3705 https://github.com/red/red/issues/3705 The fix contains a single test even though the issue provided three different failure modes: https://github.com/red/red/commit/bd41d35ee5a73cd5779647b50376b0d757c9e8a0 https://github.com/red/red/commit/bd41d35ee5a73cd5779647b503... 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? Too bad the file where the issue is fixed is this: https://github.com/red/red/blob/644be4b1e3bfcf70a5f9f5e0066fdd2cc964cd73/environment/reactivity.red https://github.com/red/red/blob/644be4b1e3bfcf70a5f9f5e0066f... 336 lines of no significant comments other than trivia for the author himself. "New line flags not cleared" whose fix is just a few lines? Oh, it's in a 3000-line file with no comments, https://github.com/red/red/blob/b7ee2846b58a1328d57002b3ed2d076d65ca4b7e/runtime/natives.reds https://github.com/red/red/blob/b7ee2846b58a1328d57002b3ed2d... And so on and so forth. 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"? ----