5 ms·

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 R

by 9214 8y ago

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. [1]: https://gitter.im/red/red https://gitter.im/red/red [2]: https://news.ycombinator.com/item?id=18348938 https://news.ycombinator.com/item?id=18348938

jungler 8y ago
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 :)
- 9214 8y ago
  Thanks for the input!
- greggirwin 8y ago
  Good feedback. Thanks.
hjek 8y ago
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.

by 9214 8y ago

jungler 8y ago

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 :)

9214 8y ago
Thanks for the input!
greggirwin 8y ago
Good feedback. Thanks.

hjek 8y ago

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.