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?
Rebol and Red are meant to be easy on its surface, while still allowing more complex stuff if you dig deeper. Of course there is a catch - e.g. if you want to modify some GUI element or create one, you need to understand all the underpinnings. On the other hand - dialects are nice way of an interfacing. I don't want to sound bold, but why Java provided its FX, or Qt its QML? Simply because once you are working in certain domain, you don't need complex language constructs.
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.
A noted, it's easy to start, but also powerful. Logo was the same. It was most well known for the turtle, but it was really Lisp, and Brian Harvey (Berkeley CS Prof) wrote a great 3-volume series called Computer Science Logo Style.
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.
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.
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.
> * 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.
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.
> 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.
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.
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.
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.
> 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.
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.
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.
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.
It is "amazingly simple to get started" but also amazingly difficult to go much deeper. Some of this, imo, is because the preferred introduction to Red/Rebol is commonly the view (GUI) subsystem. Gradual documentation or other structured paths to the deeper end of Red/Rebol appears to be non-existent.
I've seen Red compared to Lisp, Smalltalk, and Forth and other concise languages.
Anyway, the road to Red/Rebol deep mastery is heavily shrouded at present. All that said, the Red project is amazing and pretty much unique in ambition and I, for one, am certainly hoping it makes it through to a solid 1.0. At that point, I hope, strong effort will allow the language to be fully grokked by, at least, the folks who are comfortable with the likes of Lisp and Haskell.
Let's keep our fingers crossed and support the 2019 roadmap.
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 ?
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.
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.
You are right that GC s not good fit for low level programming, but Red solves this problem with dialects (DSL) of Red. For low-level it uses Red/System [1], which is C-like language with Red syntax. There are also other dialects (DSLs) for other areas like GUI, parsing, etc... It's better approach IMO than trying to solve everything with one language.
- Modula-3 at Olivetti DEC/Compaq/HP and University of Washington
- Oberon, Oberon-2, Active Oberon, Oberon-07 at ETHZ
- Oberon-07 at Astrobe
- Component Pascal at Oberon microsystems AG
- Sing#, Dafny and System C# (M#) at Microsoft Research
- Java when running AOT compiled on bare metal embedded systems like PTC Perc and Aicas Jamaica
- D by Digital Mars
- Go at Google (Fuchsia) and MIT (Biscuit)
If we don't have a mainstream OS written in one, it is mostly a consequence of politics and willingness to push it forward, instead of doing yet another UNIX clone.
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.
"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.
Generally agreed, although the huge number of bugs out there that are attributable to manual memory management suggests that other solutions are worth looking for. Perhaps Rust is heading in the right direction.
Your comment itself is extremely naive and misinformed. Red toolchain relies on Red/System DSL, which is a C-level language with manual memory management.
[+] [-] sevensor|7 years ago|reply
[+] [-] pekr|7 years ago|reply
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.
[+] [-] dockimbel|7 years ago|reply
* Language and runtime library are at version 0.6.4, so still alpha stage.
* Lack of support for mobile and web platforms (Android support is coming this year).
* Documentation is largely incomplete, still relying on Rebol docs for core parts.
* Community is very active, but still tiny, it needs to grow much bigger.
[+] [-] greggirwin|7 years ago|reply
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.
[+] [-] 9214|7 years ago|reply
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-l...
[2]: https://github.com/ldci/redCV
[3]: https://gitter.im/red/red/gui-branch?at=5c018edb8fa4333e391b...
[4]: https://gitter.im/red/red/gui-branch?at=5c03fdbabe66d8252666...
[5]: https://gitlab.com/rebolek/values
[6]: https://github.com/toomasv/drawing, https://github.com/honix/Redraw
[7]: https://www.red-lang.org/p/download.html
[8]: https://github.com/red/red/wiki/[LINKS]-Learning-resources
[9]: https://www.red-lang.org/p/about.html
[+] [-] stesch|7 years ago|reply
[+] [-] tonyjstark|7 years ago|reply
From a language standpoint, it's just a really interesting project.
[+] [-] 9214|7 years ago|reply
[+] [-] greggirwin|7 years ago|reply
[+] [-] emmanueloga_|7 years ago|reply
* 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
2: https://github.com/red/red/graphs/contributors
3: https://github.com/red/red/tree/v0.6.4
[+] [-] rebolek|7 years ago|reply
[+] [-] dockimbel|7 years ago|reply
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.
[+] [-] greggirwin|7 years ago|reply
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|7 years ago|reply
Red is implemented in Rebol2. That also comes at a cost due to Rebol2 not being free/libre and being abandoned.
[+] [-] austincheney|7 years ago|reply
Even the Wikipedia article gets this wrong: 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_deco...
[+] [-] 9214|7 years ago|reply
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_|7 years ago|reply
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.
[+] [-] lerpa|7 years ago|reply
[+] [-] lmm|7 years ago|reply
That's called not being functional. What distinction are you drawing between "functional imperative" and regular imperative languages?
[+] [-] thedeepself|7 years ago|reply
[deleted]
[+] [-] vanderZwan|7 years ago|reply
[+] [-] dvfjsdhgfv|7 years ago|reply
[+] [-] galfarragem|7 years ago|reply
[+] [-] 9214|7 years ago|reply
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.
[+] [-] decomposed|7 years ago|reply
I've seen Red compared to Lisp, Smalltalk, and Forth and other concise languages.
But Smalltalk syntax can famously be fully represented on a postcard. (https://pharoweekly.wordpress.com/2018/06/02/all-pharo-synta...) Lisp syntax is even more simple and orthogonal. (Lisp BNF http://cuiwww.unige.ch/isi/bnf/LISP/BNFlisp.html) I didn't find a good, common BNF for Forth in a quick web search but the stack is exposed and complete, standardized implementations are historically common; I did one myself once upon a time.
What about Red/Rebol? Where is the BNF?
Anyway, the road to Red/Rebol deep mastery is heavily shrouded at present. All that said, the Red project is amazing and pretty much unique in ambition and I, for one, am certainly hoping it makes it through to a solid 1.0. At that point, I hope, strong effort will allow the language to be fully grokked by, at least, the folks who are comfortable with the likes of Lisp and Haskell.
Let's keep our fingers crossed and support the 2019 roadmap.
[+] [-] Gys|7 years ago|reply
[+] [-] dvfjsdhgfv|7 years ago|reply
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|7 years ago|reply
[+] [-] neuro|7 years ago|reply
[+] [-] hu3|7 years ago|reply
Do you have any suggestion on what I could write to showcase idiomatic Rebol? Networking? GUI? Command-line?
[+] [-] thedeepself|7 years ago|reply
[deleted]
[+] [-] echelon|7 years ago|reply
[+] [-] rebolek|7 years ago|reply
[1] https://static.red-lang.org/red-system-specs.html
[+] [-] pjmlp|7 years ago|reply
- Mesa/Cedar at Xerox PARC
- Algol 68 at UK Navy computing center
- Modula-2+ at Olivetti DEC
- Modula-3 at Olivetti DEC/Compaq/HP and University of Washington
- Oberon, Oberon-2, Active Oberon, Oberon-07 at ETHZ
- Oberon-07 at Astrobe
- Component Pascal at Oberon microsystems AG
- Sing#, Dafny and System C# (M#) at Microsoft Research
- Java when running AOT compiled on bare metal embedded systems like PTC Perc and Aicas Jamaica
- D by Digital Mars
- Go at Google (Fuchsia) and MIT (Biscuit)
If we don't have a mainstream OS written in one, it is mostly a consequence of politics and willingness to push it forward, instead of doing yet another UNIX clone.
[+] [-] vardump|7 years ago|reply
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.
[+] [-] kryptiskt|7 years ago|reply
https://github.com/red/red/blob/master/runtime/collector.red...
[+] [-] zozbot123|7 years ago|reply
[+] [-] ggchappell|7 years ago|reply
[+] [-] dmitriid|7 years ago|reply
It's naive at best to assume that something isn't suitable for domains which you perceive as needing near-bare-metal performance.
E.g., your idea about games is provably false since at least IL-2 Sturmovik of 2001 which was written almost entirely in Java.
[+] [-] 9214|7 years ago|reply