Earlier quoted context omitted.
>I do not appreciate your remark about our community and Czech-speaking part of it. This is rude and uncalled for. There was no offense being given. In my experience there isn't sympathy for crying wolf here, and doing so only serves to harm whatever else you have to say.
Putting it right after "programming cult" makes misreadings very easy though. EDIT: Also, it's a bit of a silly remark because which group of programming language fanboys doesn't look a bit cult-ish to the uninitiated?
Red Programming Language: Plans for 2019
91–100 of 141 posts
Re: Red Programming Language: Plans for 2019
#92Earlier 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…
> (Are Red/Rebol creators seriously claiming that Clojure's syntax is complex?) The huge paragraph you're responding to refers to the programming stack as a whole. In reference to Clojure, it's including the JVM.
This clearly states about Clojure that its syntax AND it's procedure of development (another grand claim) introduce said complexity.
That whole write-up is just about as incorrect as it can get:
> Virtually every other well known development tool in popular use is built upon bloated layers of existing technology, [...] Most developers have just never experienced the sort of self dependent architecture,
Never mind that Red is actually implemented in another abandoned proprietary language[0]!
That entire sales pitch is a barefaced lie.
Re: Red Programming Language: Plans for 2019
#93* 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/red/blob/master/usage.txt#L68-L81
Re: Red Programming Language: Plans for 2019
#94A language with a GC does not seem appropriate for a "full-stack" language with which one would write operating systems, drivers, or game engines. I don't know why any language without full manual memory management would ever posit itself as being appropriate for these domains. It's naive at best.
"Full stack" means different things to different people. There are plenty of GC languages which are still relatively-high performance and can thus be used for technically-challenging, "system"-like tasks. In fact, this very variety is what makes it a bit hard to figure out what Red's unique selling point might be, although it's easier if you're familiar with its predecessor Rebol.
Unfortunately, they frequently lack the other attribute which makes C and C++ such pervasive solutions, namely portability.
Having "theoretical portability" (for example JVM bytecode) is not much use if your target hardware or operating system cannot support a JVM without you having to first port the JVM yourself.
Re: Red Programming Language: Plans for 2019
#95I still don't know what to make of this language. If anything, it sounds too easy, making me think "what's the catch?" Is this a small programming cult or is it Czech wizardry obscured by a language barrier? Are there no highly visible Red projects because of shortcomings in the language and its community, or because the language is so potent, its users so empowered, that big libraries aren't necessary?
As for the Czech wizardry, I might put things into some context, myself being Czech, but far from being a wizard :-) It all stems from the Amiga heritage. Remember - Rebol was created by Carl Sassenrath, Amiga OS creator, and Czech community had kind of strong following to it. Red though, is more multinational, but so was Rebol too - maybe Czechs might be more vocal here or there, in terms of the community involvements. And that's just all.
Re: Red Programming Language: Plans for 2019
#96Things 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/…
Re: Red Programming Language: Plans for 2019
#97Earlier quoted context omitted.
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…
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, fanatic…
Re: Red Programming Language: Plans for 2019
#98Is there a catch? Yes. More than one actually. One is that, because we are building things from the ground up, we don't get things for free that other languages do. For example, JVM-based langs get a lot for free, but at a cost. Another catch, and a big one, is that Red is fundamentally different in some design aspects, both superficial (syntax) and deep (all is data, words and bindings, etc.). Those two things deter a lot of people. We get that. If you want to keep doing things mostly the way you always have, Red is not for you. If you just want lots of familiar libs and features, you may have to wait for them, or help build them. This makes us a self-selecting community. We don't want to be a cult, but we also won't compromise certain things with the hope of it making us more popular. There are few easy choices here.
For those who find Red, and give it a shot, not all will like it, and not all who like it will understand it or use it effectively. We also accept that. For those who have the courage to try something new (I mean, really try it), and who take the time to understand it (the process of which brings its own benefits, no matter what language you use), and who reach the moment where it clicks in their head, there is no going back.
Whether you support and commend features, or criticize them fairly, they are features. To have meaningful discourse about Red, we need to go deeper. Much deeper. If you only want to compare Red to other tools, on their terms, we'll often lose. But if you look at what Red can do, that they can't, and Red's fundamental goals, it becomes clear that comparisons don't mean much. That's true for any 2 languages. It can help, provide context, etc., but ultimately you have to evaluate a language or tool on its own merits, just as you have to evaluate yourself and see your own worth and value without comparison to others.
If you think the state of software development is just fine, and a few tweaks are all we need, Red probably isn't for you. But if you have nagging doubts about why things are so hard, so big, so complex, when it seems like they should be easy, small, and simple...maybe you'll be curious and brave enough to take the Red pill. Most, we know, just want the big juicy steak.
We can talk more, explain more, if people want. Gitter is our most active channel, but we can try to respond here as well. We're glad to hear what people like, and accept fair criticism.
Re: Red Programming Language: Plans for 2019
#99I still don't know what to make of this language. If anything, it sounds too easy, making me think "what's the catch?" Is this a small programming cult or is it Czech wizardry obscured by a language barrier? Are there no highly visible Red projects because of shortcomings in the language and its community, or because the language is so potent, its users so empowered, that big libraries aren't necessary?
Red is potent, but also Alpha.
Big libraries are rarely needed. e.g., we have a native image datatype, and codecs for 4 common image formats. No external libs needed. The GUI system is built in, though it added to our size quite a bit. We're over 1MB now.
Re: Red Programming Language: Plans for 2019
#100Earlier 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…
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.
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 cleared on subsequent calls, https://github.com/red/red/issues/3707
Fix: 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
The fix contains a single test even though the issue provided three different failure modes: 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/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/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"? ----