15 ms·

Red Programming Language: Plans for 2019

185 points by rebolek 8y ago

vanderZwan 8y ago
I was so worried when they announced their cryptocurrency plans that Red wouldn't survive when the cryptocurrency hype bubble would inevitably pop. Glad to see that they managed.
- dvfjsdhgfv 8y ago
  I was worried about it too. I hope they simply forget about the whole ICO thing and just move forward.
  - 9214 8y ago
    Unlike the majority of startups in crypto space, the team is actually dedicated to bring the value to this ecosystem. Ethereum roller-coaster forced a constant change of plans, but, as far as I know, no one ditched gived promises and just moved forward.
Gys 8y ago
A great feature of Red is their cross platform GUI support. I see Android is also supported. Does anyone know what the status of iphone (iOS) support is ?
- dvfjsdhgfv 8y ago
  I wouldn't call its GUI really cross-platform yet. Linux GUI definitely isn't production ready. Android is somewhat usable. iOS is not working. Nevertheless, I keep my fingers crossed. My estimate is in 2-3 years you will be able to start writing small cross-platform GUI apps in RED and not worry about trifle problems.
  - 9214 8y ago
    One major stumble block in GTK backend development is a monstrocious string-oriented API for setting widget properties. There's a more low-level one, but it's depricated. FYI, development of backend happens as we speak [1]. [1]: https://gitter.im/red/GTK https://gitter.im/red/GTK
  - greggirwin 8y ago
    This came up not long ago, and we have to define "cross platform" to say whether Red meets the criteria. Red does have a cross platform GUI system, though it is only fully implemented on MacOS and Windows currently. We don't run on iOS at all yet. What the current system shows is that a single, cross platform dialect can abstract away the native OS APIs in a clean way, though there will always be tradeoffs, as every OS has different features. The RED Wallet is an example of a cross platform app, done today.
- 9214 8y ago
  No official support, but things may change in the upcoming year.
stesch 8y ago
I'm I shallow if I stopped caring about this project after they started with all this crypto currency stuff?
- 9214 8y ago
  I'd say your reaction is understandable, but unfairly biased.
- tonyjstark 8y ago
  I also had strong opinions about this at first. Then I thought, better they get some money through this than all the projects out there that are obviously scams. If they have fun with their C3 language and their interfaces to whatever blockchain, good for them, at least they use the money to drive Red forward. Also happy they didn't lose everything with the last crash. From a language standpoint, it's just a really interesting project.
- greggirwin 8y ago
  If you read the old blog entries about why it was done, do you still feel that way?
  - stesch 8y ago
    I followed the project up until then.
    - greggirwin 8y ago
      Understood, so you know there was a reason for branching out into the blockchain space, as there's a real need for better langs there, and less competition, which leads to more visibility in an area that his hot technology. For the project to survive, we'll have to try a lot of things.
austincheney 8y ago
The Red Language has always described itself as functional imperative. I used to point out to people that functional programming can be imperative and nobody (I do mean nobody I spoke to about this) would believe me on this. Then I would point out to people Red Language as an example and they would scratch their heads in confusion. Even the Wikipedia article gets this wrong: https://en.wikipedia.org/wiki/Functional_programming https://en.wikipedia.org/wiki/Functional_programming Functional imperative is the idea of using functions to define the shape of an application, which is to say the nesting of functions defines both the stacked structure and the resulting control flow opposed to describing units of logic or any sort of reflection. https://en.wikipedia.org/wiki/Function_model#Functional_decomposition https://en.wikipedia.org/wiki/Function_model#Functional_deco...
- 9214 8y ago
  Idiomatically written Red is largerly data-driven, composed out of mini languages and micro formats (dialects), with huge emphasis on homoiconicity and rich set of available datatypes. Functions indeed are mostly used to guide the flow of program and stack dialects on top of one another, so the resulting app is like a dedicated toolchain (or even a VM), where each component is a small interpreter or compiler.
- bjz_ 8y ago
  > I used to point out to people that functional programming can be imperative and nobody (I do mean nobody I spoke to about this) would believe me on this. Interesting. Monadic Haskell can be quite imperative if you want it to be, as can SML or OCaml. Scheme and Lisp have imperative parts too.
  - macintux 8y ago
    Ditto Erlang.
  - grenadier21 8y ago
    Haskell's IO is literally the idea of sequencing commands reified, though, so the comparison is a bit apples-to-oranges.
echelon 8y ago
A 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.
- vardump 8y ago
  I write kernel drivers and firmware code mainly in C and a little bit of assembler. I agree with you pretty much. That said, it's healthy to have some people exploring alternative paths. Maybe some of that exploration will be fruitful, way or another. Especially firmware development is somewhat ossified to C. C is universally supported and a lot of people in this trade don't even see need for a change, despite vastly increased system complexity and exposure over open networks. It's not enough for the things to just to work — they need to work securely, otherwise ultimately our infrastructure is at risk. C can work with 16 bytes to 16 TB+ (or a lot more) of RAM. It can span from a 4-bit single core microcontrollers to massive RDMA supercomputing clusters. C contender does not need to cover all of that, but should keep that enormous range in mind. The contender should also be able to interface with C library and linking interfaces. Otherwise it's hard to compose working systems. No matter how amazing the new language is, you can't build everything from scratch. So far I've placed my biggest hopes in Rust. But we'll see how the things evolve. One should keep an open mind. I wish good luck for the Red folks. By the way, you often can't allocate or free memory in firmware or kernel drivers either. Like in a kernel IRQ handler or on an embedded device with hard realtime and stability requirements. In that kind of case GC or manual allocation would not make much difference at all — you'd only allocate at initialization or at teardown.
  - grenadier21 8y ago
    C doesn't even assume that code and memory live in the same address space! The portability of standard C is almost as breathtaking as the ease with which you can introduce undefined behavior.
  - cmiller1 8y ago
    >That said, it's healthy to have some people exploring alternative paths. Maybe some of that exploration will be fruitful, way or another. Exactly. Perhaps it is not appropriate to write production ready drivers and operating systems that people will use today in a GC language; but in the future that could change and change will only happen if people take the time to experiment.
neuro 8y ago
After seeing the first demos from Rebol View many years ago, nothing comes close yet.
- hu3 8y ago
  At least once a year I'm tempted to play with Rebol. Its concepts scratches many itches of mine. Do you have any suggestion on what I could write to showcase idiomatic Rebol? Networking? GUI? Command-line?
  - neuro 8y ago
    Take a look at these, source code is easy to follow http://www.rebol.com/pre-view.html http://www.rebol.com/pre-view.html
galfarragem 8y ago
Isn't Red a great language to teach children? I just tried Red and it's amazingly simple to get started.
- 9214 8y ago
  Although Logo is said to be an ancestor to Rebol (which in turn is an ancestor to Red), there's more it than an apparent "childish" simplicity on the surface. http://www.rebol.com/article/0103.html http://www.rebol.com/article/0103.html Language that hits the sweet spot between Forth and Lisp might be a good fit for some kids, but its scope is way outside of mere scripting and toying, and demands a respective approach - something that only grown-up engineers can fully appreciate. YMMW.
  - Izkata 8y ago
    It's been 19 years since I started learning to program with Rebol, it's still my go-to language for personal projects.
  - vanderZwan 8y ago
    > its scope is way outside of mere scripting and toying, and demands a respective approach Maybe I misunderstand where you are coming from, but to me this appears similar to saying that using acrylic paint demands a respective approach because the great paintings of the last century were made with it. To which I would say: no, not really. Acrylic paint only demands a respective approach in the sense that it may be toxic and you don't want kids to finger paint or risk swallowing it. But people can paint whatever they want with it. Similarly, Red demands a respective approach because it's powerful enough to shoot yourself in the foot (oops, some kid deleted half of the files on the SSD by accident). Maybe that is what you meant with "scope", but it's not what I made out of it upon first reading. Besides, the solution for that is simple enough: make a child-safe dialect.
    - 9214 8y ago
      My point is that Rebol and Red are extremely good chameleons - they hide all their power behind the approachable facade, and make a false impression of "oh it's just X, nothing serious". I saw a fair share of people who, based on that first impression, dismiss Red as a quirky alternative to Python, or a GUI-building kit, or a pretentious academical toy, you name it. But that doesn't mean that these languages child-safe by default, and indeed, foot-shooting starts as soon as you begin to harness that power - that's where the real fun is, which IMO kids can't appreciate fully. As you said, it's anything but a finger paint. But if it clicks in kid's brain from the get-go and grows over him, then the world is ought to see some great paintings ;)
sevensor 8y ago
I 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?
- 9214 8y ago
  I do not appreciate your remark about our community and Czech-speaking part of it. This is rude and uncalled for. Regardless of gender and nationality of community members, and despite the fact that Red is an alpha software, the following projects were created, which may qualify as highly visible: * neural networks [1] * computer vision framework [2] * dataflow engine [3] * ports of (cross-platform) GUI widgets [4] * projectional editor [5] * drawing apps [6] * operating systems (an in-house project as of now, so no link) If you don't know what to make out of Red, I'd suggest to grab the latest build [7] with a list of learning resources [8] and do a bit of research. Official About page [9] also gives a good list of main features. Big libraries indeed aren't necessary, because most of batteries are included in a 1MB executable, and common needs are covered by core library. Full-fledged module system is missing, but is planned for 0.8.0 release. We also have a large Rebol ecosystem, from which various scripts and applications may be ported, if necessary. [1]: http://redlcv.blogspot.com/2018/11/neural-network-with-red-language.html http://redlcv.blogspot.com/2018/11/neural-network-with-red-l... [2]: https://github.com/ldci/redCV https://github.com/ldci/redCV [3]: https://gitter.im/red/red/gui-branch?at=5c018edb8fa4333e391b867a https://gitter.im/red/red/gui-branch?at=5c018edb8fa4333e391b... [4]: https://gitter.im/red/red/gui-branch?at=5c03fdbabe66d825266600ac https://gitter.im/red/red/gui-branch?at=5c03fdbabe66d8252666... [5]: https://gitlab.com/rebolek/values https://gitlab.com/rebolek/values [6]: https://github.com/toomasv/drawing https://github.com/toomasv/drawing, https://github.com/honix/Redraw https://github.com/honix/Redraw [7]: https://www.red-lang.org/p/download.html https://www.red-lang.org/p/download.html [8]: https://github.com/red/red/wiki/[LINKS]-Learning-resources https://github.com/red/red/wiki/[LINKS]-Learning-resources [9]: https://www.red-lang.org/p/about.html https://www.red-lang.org/p/about.html
thedeepself 8y ago
I'm hungry for web app development in Red and good ORM support.
emmanueloga_ 8y ago
Things 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/red/blob/master/usage.txt#L68-L81 https://github.com/red/red/blob/master/usage.txt#L68-L81 2: https://github.com/red/red/graphs/contributors https://github.com/red/red/graphs/contributors 3: https://github.com/red/red/tree/v0.6.4 https://github.com/red/red/tree/v0.6.4
- rebolek 8y ago
  It didn't take 8 years to get simple GC, it just wasn't high priority earlier.
- dockimbel 8y ago
  > * Apparently, it took it 8 years to get simple (in words of author) G.C. [3] Apparently you didn't look close enough at the history and are making up fake information. Preliminary work on GC started in 2017 for a month, then resumed in 2018 for about 3-4 months. So in total, about 4-5 months, mostly spent on adjusting the runtime library and tracking notoriously hard to catch GC-related issues.
  - emmanueloga_ 8y ago
    Hey there, I did not intend to imply it took that long in actual development time, more in the sense that the g.c. feature did not exist in He language for that long, for different reasons (evidently it wasn’t a priority). A dynamic language without g.c. sounds dangerous to use. I’m just surprised it wasn’t a priority for so long.
greggirwin 8y ago
There are a lot of topics here now, which is great, and the opening question about what to make of Red is a good one. The problem in answering it is the same problem we have when pitching it to people: it's hard to sum up. Is 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.
- hjek 8y ago
  > 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. Red is implemented in Rebol2. That also comes at a cost due to Rebol2 not being free/libre and being abandoned.

185 points by rebolek 8y ago

I was so worried when they announced their cryptocurrency plans that Red wouldn't survive when the cryptocurrency hype bubble would inevitably pop. Glad to see that they managed.

dvfjsdhgfv 8y ago
I was worried about it too. I hope they simply forget about the whole ICO thing and just move forward.
- 9214 8y ago
  Unlike the majority of startups in crypto space, the team is actually dedicated to bring the value to this ecosystem. Ethereum roller-coaster forced a constant change of plans, but, as far as I know, no one ditched gived promises and just moved forward.

Gys 8y ago

A great feature of Red is their cross platform GUI support. I see Android is also supported. Does anyone know what the status of iphone (iOS) support is ?

dvfjsdhgfv 8y ago
I wouldn't call its GUI really cross-platform yet. Linux GUI definitely isn't production ready. Android is somewhat usable. iOS is not working. Nevertheless, I keep my fingers crossed. My estimate is in 2-3 years you will be able to start writing small cross-platform GUI apps in RED and not worry about trifle problems.
- 9214 8y ago
  One major stumble block in GTK backend development is a monstrocious string-oriented API for setting widget properties. There's a more low-level one, but it's depricated. FYI, development of backend happens as we speak [1]. [1]: https://gitter.im/red/GTK https://gitter.im/red/GTK
- greggirwin 8y ago
  This came up not long ago, and we have to define "cross platform" to say whether Red meets the criteria. Red does have a cross platform GUI system, though it is only fully implemented on MacOS and Windows currently. We don't run on iOS at all yet. What the current system shows is that a single, cross platform dialect can abstract away the native OS APIs in a clean way, though there will always be tradeoffs, as every OS has different features. The RED Wallet is an example of a cross platform app, done today.
9214 8y ago
No official support, but things may change in the upcoming year.

stesch 8y ago

I'm I shallow if I stopped caring about this project after they started with all this crypto currency stuff?

9214 8y ago
I'd say your reaction is understandable, but unfairly biased.
tonyjstark 8y ago
I also had strong opinions about this at first. Then I thought, better they get some money through this than all the projects out there that are obviously scams. If they have fun with their C3 language and their interfaces to whatever blockchain, good for them, at least they use the money to drive Red forward. Also happy they didn't lose everything with the last crash. From a language standpoint, it's just a really interesting project.
greggirwin 8y ago
If you read the old blog entries about why it was done, do you still feel that way?
- stesch 8y ago
  I followed the project up until then.
  - greggirwin 8y ago
    Understood, so you know there was a reason for branching out into the blockchain space, as there's a real need for better langs there, and less competition, which leads to more visibility in an area that his hot technology. For the project to survive, we'll have to try a lot of things.

austincheney 8y ago

The Red Language has always described itself as functional imperative. I used to point out to people that functional programming can be imperative and nobody (I do mean nobody I spoke to about this) would believe me on this. Then I would point out to people Red Language as an example and they would scratch their heads in confusion. Even the Wikipedia article gets this wrong: https://en.wikipedia.org/wiki/Functional_programming https://en.wikipedia.org/wiki/Functional_programming Functional imperative is the idea of using functions to define the shape of an application, which is to say the nesting of functions defines both the stacked structure and the resulting control flow opposed to describing units of logic or any sort of reflection. https://en.wikipedia.org/wiki/Function_model#Functional_decomposition https://en.wikipedia.org/wiki/Function_model#Functional_deco...

9214 8y ago
Idiomatically written Red is largerly data-driven, composed out of mini languages and micro formats (dialects), with huge emphasis on homoiconicity and rich set of available datatypes. Functions indeed are mostly used to guide the flow of program and stack dialects on top of one another, so the resulting app is like a dedicated toolchain (or even a VM), where each component is a small interpreter or compiler.
bjz_ 8y ago
> I used to point out to people that functional programming can be imperative and nobody (I do mean nobody I spoke to about this) would believe me on this. Interesting. Monadic Haskell can be quite imperative if you want it to be, as can SML or OCaml. Scheme and Lisp have imperative parts too.
- macintux 8y ago
  Ditto Erlang.
- grenadier21 8y ago
  Haskell's IO is literally the idea of sequencing commands reified, though, so the comparison is a bit apples-to-oranges.

echelon 8y ago

A 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.

vardump 8y ago
I write kernel drivers and firmware code mainly in C and a little bit of assembler. I agree with you pretty much. That said, it's healthy to have some people exploring alternative paths. Maybe some of that exploration will be fruitful, way or another. Especially firmware development is somewhat ossified to C. C is universally supported and a lot of people in this trade don't even see need for a change, despite vastly increased system complexity and exposure over open networks. It's not enough for the things to just to work — they need to work securely, otherwise ultimately our infrastructure is at risk. C can work with 16 bytes to 16 TB+ (or a lot more) of RAM. It can span from a 4-bit single core microcontrollers to massive RDMA supercomputing clusters. C contender does not need to cover all of that, but should keep that enormous range in mind. The contender should also be able to interface with C library and linking interfaces. Otherwise it's hard to compose working systems. No matter how amazing the new language is, you can't build everything from scratch. So far I've placed my biggest hopes in Rust. But we'll see how the things evolve. One should keep an open mind. I wish good luck for the Red folks. By the way, you often can't allocate or free memory in firmware or kernel drivers either. Like in a kernel IRQ handler or on an embedded device with hard realtime and stability requirements. In that kind of case GC or manual allocation would not make much difference at all — you'd only allocate at initialization or at teardown.
- grenadier21 8y ago
  C doesn't even assume that code and memory live in the same address space! The portability of standard C is almost as breathtaking as the ease with which you can introduce undefined behavior.
- cmiller1 8y ago
  >That said, it's healthy to have some people exploring alternative paths. Maybe some of that exploration will be fruitful, way or another. Exactly. Perhaps it is not appropriate to write production ready drivers and operating systems that people will use today in a GC language; but in the future that could change and change will only happen if people take the time to experiment.

neuro 8y ago

After seeing the first demos from Rebol View many years ago, nothing comes close yet.

hu3 8y ago
At least once a year I'm tempted to play with Rebol. Its concepts scratches many itches of mine. Do you have any suggestion on what I could write to showcase idiomatic Rebol? Networking? GUI? Command-line?
- neuro 8y ago
  Take a look at these, source code is easy to follow http://www.rebol.com/pre-view.html http://www.rebol.com/pre-view.html

galfarragem 8y ago

Isn't Red a great language to teach children? I just tried Red and it's amazingly simple to get started.

9214 8y ago
Although Logo is said to be an ancestor to Rebol (which in turn is an ancestor to Red), there's more it than an apparent "childish" simplicity on the surface. http://www.rebol.com/article/0103.html http://www.rebol.com/article/0103.html Language that hits the sweet spot between Forth and Lisp might be a good fit for some kids, but its scope is way outside of mere scripting and toying, and demands a respective approach - something that only grown-up engineers can fully appreciate. YMMW.
- Izkata 8y ago
  It's been 19 years since I started learning to program with Rebol, it's still my go-to language for personal projects.
- vanderZwan 8y ago
  > its scope is way outside of mere scripting and toying, and demands a respective approach Maybe I misunderstand where you are coming from, but to me this appears similar to saying that using acrylic paint demands a respective approach because the great paintings of the last century were made with it. To which I would say: no, not really. Acrylic paint only demands a respective approach in the sense that it may be toxic and you don't want kids to finger paint or risk swallowing it. But people can paint whatever they want with it. Similarly, Red demands a respective approach because it's powerful enough to shoot yourself in the foot (oops, some kid deleted half of the files on the SSD by accident). Maybe that is what you meant with "scope", but it's not what I made out of it upon first reading. Besides, the solution for that is simple enough: make a child-safe dialect.
  - 9214 8y ago
    My point is that Rebol and Red are extremely good chameleons - they hide all their power behind the approachable facade, and make a false impression of "oh it's just X, nothing serious". I saw a fair share of people who, based on that first impression, dismiss Red as a quirky alternative to Python, or a GUI-building kit, or a pretentious academical toy, you name it. But that doesn't mean that these languages child-safe by default, and indeed, foot-shooting starts as soon as you begin to harness that power - that's where the real fun is, which IMO kids can't appreciate fully. As you said, it's anything but a finger paint. But if it clicks in kid's brain from the get-go and grows over him, then the world is ought to see some great paintings ;)

sevensor 8y ago

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

9214 8y ago
I do not appreciate your remark about our community and Czech-speaking part of it. This is rude and uncalled for. Regardless of gender and nationality of community members, and despite the fact that Red is an alpha software, the following projects were created, which may qualify as highly visible: * neural networks [1] * computer vision framework [2] * dataflow engine [3] * ports of (cross-platform) GUI widgets [4] * projectional editor [5] * drawing apps [6] * operating systems (an in-house project as of now, so no link) If you don't know what to make out of Red, I'd suggest to grab the latest build [7] with a list of learning resources [8] and do a bit of research. Official About page [9] also gives a good list of main features. Big libraries indeed aren't necessary, because most of batteries are included in a 1MB executable, and common needs are covered by core library. Full-fledged module system is missing, but is planned for 0.8.0 release. We also have a large Rebol ecosystem, from which various scripts and applications may be ported, if necessary. [1]: http://redlcv.blogspot.com/2018/11/neural-network-with-red-language.html http://redlcv.blogspot.com/2018/11/neural-network-with-red-l... [2]: https://github.com/ldci/redCV https://github.com/ldci/redCV [3]: https://gitter.im/red/red/gui-branch?at=5c018edb8fa4333e391b867a https://gitter.im/red/red/gui-branch?at=5c018edb8fa4333e391b... [4]: https://gitter.im/red/red/gui-branch?at=5c03fdbabe66d825266600ac https://gitter.im/red/red/gui-branch?at=5c03fdbabe66d8252666... [5]: https://gitlab.com/rebolek/values https://gitlab.com/rebolek/values [6]: https://github.com/toomasv/drawing https://github.com/toomasv/drawing, https://github.com/honix/Redraw https://github.com/honix/Redraw [7]: https://www.red-lang.org/p/download.html https://www.red-lang.org/p/download.html [8]: https://github.com/red/red/wiki/[LINKS]-Learning-resources https://github.com/red/red/wiki/[LINKS]-Learning-resources [9]: https://www.red-lang.org/p/about.html https://www.red-lang.org/p/about.html

thedeepself 8y ago

I'm hungry for web app development in Red and good ORM support.

emmanueloga_ 8y ago

Things 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/red/blob/master/usage.txt#L68-L81 https://github.com/red/red/blob/master/usage.txt#L68-L81 2: https://github.com/red/red/graphs/contributors https://github.com/red/red/graphs/contributors 3: https://github.com/red/red/tree/v0.6.4 https://github.com/red/red/tree/v0.6.4

rebolek 8y ago
It didn't take 8 years to get simple GC, it just wasn't high priority earlier.
dockimbel 8y ago
> * Apparently, it took it 8 years to get simple (in words of author) G.C. [3] Apparently you didn't look close enough at the history and are making up fake information. Preliminary work on GC started in 2017 for a month, then resumed in 2018 for about 3-4 months. So in total, about 4-5 months, mostly spent on adjusting the runtime library and tracking notoriously hard to catch GC-related issues.
- emmanueloga_ 8y ago
  Hey there, I did not intend to imply it took that long in actual development time, more in the sense that the g.c. feature did not exist in He language for that long, for different reasons (evidently it wasn’t a priority). A dynamic language without g.c. sounds dangerous to use. I’m just surprised it wasn’t a priority for so long.

greggirwin 8y ago

There are a lot of topics here now, which is great, and the opening question about what to make of Red is a good one. The problem in answering it is the same problem we have when pitching it to people: it's hard to sum up. Is 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.

hjek 8y ago
> 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. Red is implemented in Rebol2. That also comes at a cost due to Rebol2 not being free/libre and being abandoned.