Red: A programming language inspired by REBOL
github.com
github.com
[1]: https://news.ycombinator.com/item?id=27820141
Then, I decided to google some keywords (like GUI DSLs) limiting it to HN threads. Someone suggested: 'this is essentially REBOL...'. Then I went to this rabbit-hole of REBOL, RED, homoiconicity, DSLs....
Fun Fact: Did you know the whole compiler and interpreter of Red with all batteries included (including cross-platfrom GUI bindings) is a ~1 MiB single binary?!!
Some links:
Red's originator talk: https://www.youtube.com/watch?v=-KqNO_sDqm4
Red sample programs: https://github.com/red/community/
Especially this `parse` dialect seem to be a "readable" regexp: https://github.com/red/community/tree/master/parse
If they ever get it working as intended, it will be a game changer to be able to write small executables with a GUI, DSLs...etc while staying so lightweight. Good luck to the team. It's been a little weird that I haven't seen a new blog post in so long (almost a year), when updates used to happen fairly often.
They seemed to have been derailed by the focus on crypto-currency as a solution to funding.
In a bitter irony, they were too early to the party. Had they continued momentum on regular work, they could now have used gitcoin to fund work.
I hope this project continues though. I wish them nothing but the best!
We absolutely lost some focus with the blockchain aspect, and are rolling with all the punches as best we can. Sustainability is key, so we're also working on commercial products to that end. Got our first one out last year, and the next one is in the planning stages.
Our first product is https://www.redlake-tech.com/products/diagrammar-for-windows..., and all features are enabled for free. The only limitation is that exported images are watermarked. We also sponsor licenses for other FOSS projects.
It's funny to me what a tough sell it is, but that's true for all new dev tools. While the main purpose is to help anyone, whatever grammar they choose (ABNF, EBNF, etc.), it all compiles down to Red `parse` internally, so if you use Red, your parser is already done. If you use the native `parse` rules to begin with, you can even include actions. Testing in it is cool too. But really it's to try and get people to see that documenting your design (meaning you have a design to begin with), is valuable.
The only place I go to see updates for projects is Releases (or a changelog file).
Maybe a nice middle ground is simply writing more blog posts? I believe this comment from the blog sums it up very well:
> The last post here was April 20 and on Twitter Red-lang, Oct 20, of last year. Never feel like the teams posts must be somewhat ground breaking or totally exciting to the general reader/supporter. We and new interested parties must see you are still supporting your own vision or like a slow loading web page they'll be forced to move on.
https://www.red-lang.org/2020/08/redsystem-new-features.html...
I hope Red turns out better, but they're a bit late to the party, and need a lot more hands to evolve. Since I'm not in a position to help, I'll stick with Go + fyne for whatever can't be a web app.
Worth pointing out that those are becoming increasingly uncommon, with Apple already having dropped it, and Microsoft dropping it from Windows 11 (EDIT: okay, I misremembered: Microsoft is dropping support for 32 bit installs, not WoW64). For the moment, 32 bit x86 multilib is still common on Linux, but I wouldn't be surprised to see it start to disappear in the next 5-10 years.
So this isn't an immediate problem for most people not running MacOS, but will eventually be a pretty big problem in the next decade for this project.
So basically no more NTVDM now, forevermore? :(
Now I mostly work on macOS for mobile apps development, and sadly can't run Red.
https://news.ycombinator.com/item?id=18843544
Plus the square brackets are easier to type than the round ones.
Overall the design of REBOLs is pretty interesting and IMO somewhat reminiscent of Tcl. Both are certainly good inspirations for minimalist language designers.
There are over 13,000 commits in nearly 10 years and it has been discussed dozens of times on HN. I understand it isn't old, but is this actually new?
It shares syntax with Rebol, 95% of it anyway, but many other "new" languages share syntax with older languages. In any case, there are many new things about it, including being a from-scratch implementation.
- Native GUI system (non-native in development for those who want to go that way) driven by a GUI DSL, with full reactivity built in. - Reactivity and ownership features are built into the core object datatype, so they can be used for more than GUIs. - System level DSL. Red/System is a C level language, but is a dialect of Red. It compiles directly to machine code, not ASM or C. Cross compilation is built in as well. Again, no external tools needed. - Android is out of date, but it also requires no JDK or other IDE.
So there are at least some things that make it new-ish.
http://www.rebol.com/docs.html
Note, OP likely talking about Rebol 2.
Rebol 3 and Red were/are (sort of) forks...
Rebol's designer called this "definitional scoping". What it means is that where a word (variable) exists is important. The "where" part leads to https://github.com/red/red/wiki/%5BDOC%5D-Why-you-have-to-co... and is one of the big things that messes with your head when you come to Red from other langs. :^) For many people this stays invisible forever and things just work. But it doesn't take much for people to step off the ledge and into deep water, because things look so easy and it seems like you should be able to just pass blocks around and have everything work magically. It's internally consistent in how it works, but that's hard to see without tooling we have yet to build.
Rust's `macro_rules!` macros operate on ASTs, so the `x` inside a macro definition is different to the `x` in the scope where the macro is used, even though the textual representation of the identifier the macro inserts into the place it's used might be identical. This means that:
macro_rules! add_two {
($i: ident) => {
let x = 2;
$i += x;
}
}
fn main() {
let mut x = 5;
add_two!(x);
println!("{}", x);
}
appears to become: fn main() {
let mut x = 5;
let x = 2;
x += x;
println!("{}", x);
}
but it still prints 7, not 4, because they're two different `x`s. (Of course, Red has first-class metaprogramming, so it's a lot better.)Scripting languages are much closer to Lisp than to C (e.g. compare Python to Racket).
IIRC Ruby, Javascript and Smalltalk (the latter inspiring a lot of OOP languages) were all explicitly designed to be like Lisp.
It should give you place to get started. The cliff node what I did is the I wrote a function that replaces things in a list of lists/a tree and used that rewrite the definition of the function to make it more readable. While it is an toy example I hope it helps.
Carl Sassenrath apparently got a knack for pulling that off.
Absolutely.-
Yes, if you rebuild the runtime when you compile, it's slow. If you use dev mode, because you're not changing anything in the runtime, it's fast.
Let's see. Java? Python? Ruby? JS? PHP? Any .NET lang?
Go is on the rise, yes. As is Rust. But D? Nim? Do you really consider those major languages?
Enough silly arguments though. We think it's special to offer options, because one size does not fit all, but we hope a common syntax can fit most. So you have the option to 1) use an external runtime, which makes all your EXEs tiny (say they run in a common system, even against a custom Red runtime you build); 2) compile to native code and get a single, no dependencies, EXE; 3) "encap" your code with the compiled runtime so you can leverage all dynamic features of Red, some of which can't be compiled; 4) compile the runtime so it can be accessed from other languages and environments. 5) Write in pure Red/System, which is basically like writing in C. Maximum control, no high level features. Tiny EXEs, no runtime, fast compilation.
- https://www.red-lang.org/2017/03/062-libred-and-macros.html (please note the Excel+Red Pong demo)
this has already been explained, and i am only repeating it here for the casual HN reader, so they can follow along.
old comment, that makes no sense because getting a fast static build isn't even a problem. left here because that is what was responded to:
why do you need a static build after every change? isn't a dynamic one sufficient for testing?
It sounds like you're describing an edge case. To better understand it, what's the actual context around your requirement of static builds?
To be clear about my question, I am genuinely curious - perhaps there are workarounds that could be used, or optimizations that could be considered in the long term.
However (and critically), there is not nearly enough semantic detail in your arguments as currently presented for developers to potentially extract actionable work items from. This is why everyone else is annoyed.
Any reason this wouldn't work?
https://github.com/red/red/issues/3417#issuecomment-39667197...