Hacker News new | past | comments | ask | show | jobs | submit login
Red: A programming language inspired by REBOL (github.com/red)
106 points by ducktective 6 months ago | hide | past | favorite | 56 comments



This language has been under my radar for some time. Recently, I asked a question about "automatic GUI creators" [1] but suggestions were not what I was looking for.

[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


On my radar for ages as well, but it's never quite ready. Very ambitious.

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.


As far I remember it started declining after they jumped on the ICO bandwagon. I didn’t really follow it that much after that..


Yeah I stopped being interested as soon as they started talking about some dumb-ass coin.


No release since 2018?

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!


Automated builds are the way to go. We're revamping our release process to avoid stale-binary syndrome. If you don't follow us on Gitter, where you'll see active chat every day, you can look at https://progress.red-lang.org/ to see what's been done. Or just look at github graphs of commits.

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.


The problem with going off of commits is that if someone doesn’t follow every week, they are likely to miss what is happening.

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


Diagrammar looks interesting. Is there enough demand for it though? Wish y'all the best!


That's what we're trying to find out. :^) In many ways it is a guinea pig, and something we wanted for ourselves. Very niche, to be sure, but if you've ever had to write grammars, the alternatives are EMACS/VIM + YACC/Bison or XText if you're in the Java world and can be locked in and handle the weight.

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.


It seems pretty similar to this free one

https://github.com/GuntherRademacher/rr


They generate the same type of syntax diagram, but are otherwise...quite different. If you read the product page it should hit the high points.



Those are the same project.


In my opinion REBOL was a great idea, and I also wrote quite a few extremely terse but readable inhouse apps before REBOL v2 development completely halted, and a useable v3 never materialized. As proprietary payware, it didn't really stand a chance.

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.


I've only obliquely heard of REBOL. I looked at this article (linked from the Red documentation) about GUIs. You're spot on: extremely terse but readable - http://www.mycode4fun.co.uk/About-Red-Programming


Should mention it won't run on 64bit OSes:

https://github.com/red/red/issues/4359


Won't run on 64 bit only OSes. OSes with 32 bit multilib runtimes will do fine.

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.


Wait what.

So basically no more NTVDM now, forevermore? :(


Yeah that's still an unsolved issue.

Now I mostly work on macOS for mobile apps development, and sadly can't run Red.


64-bit is high on our list, but also a huge task, so needs a large block of time where other things won't get done. We have some big features we're pushing on now, and will update our roadmap accordingly.



What is nicer syntax-wise in Red/REBOL compared to Lisp is the slightly lower number of brackets and nesting. And the C-style formatting of brackets -- with closing brackets aligned with their counterparts. It is a little more verbose, but easier to read.

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.


First line of the readme: Red is a *new* programming language strongly inspired by Rebol.

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?


Of course we have to define "new". And consider that it was new when that was written. :^)

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.


REBOL was so far ahead of its time ...


As an old Lisp/Scheme guy all I can think whenever I try to figure out what is going on with Rebol/Red is "What a mess."


Can you please elaborate? ;) As a person who has 0 knowledge on the likes of PROLOG, LISP, etc...What makes LISP and LISP-like languages so great? I tried to search YouTube on the merits of LISP or this notion of "data as code" but nothing tangible came up... I mean LISP is one of the oldest languages with really weird features w.r.t to C-like languages but in practice we only see C-likes...even Rust is not so different from this family of languages...


> I mean LISP is one of the oldest languages with really weird features w.r.t to C-like languages but in practice we only see C-likes

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.


I gave a lightning talk in (German) about meta programming and equivalence of code and data in PicoLisp by example. 16:16 https://media.ccc.de/v/froscon2018-2322-lightning_talks#t=97...

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.


What mess do you mean? The language, what happened to the language because of Rebol Technologies, or something else?


I think modern concept-equivalent would be Racket with its visual features out of the box. In practice, though, it's unsustainable because of different OS graphics stack, complexity of frameworks like Qt and GTK that themselves changing often, the speed of changes in underlying draw technologies, etc.



One of my modest ambitions is to finally understand how Scopes work in REBOL


One of our team summed it up very nicely: Pragmatically, this design notion comes from Red being a data format first (code is data and data can be used as code). To mimick scoping at data level, context has to be implicit. As a consequence, any block of code e.g. [take the spoon] can be passed around, evaluated on demand in any place, used in user-defined custom loops, without losing the original meaning even if all it's words `take`, `the` and `spoon` were defined differently in those loops or other functions.

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.


Oh, so it's like Rust's `macro_rules!` identifier rule?

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


Something like that, yes. Red has macros as well, with a key difference being that at compile time, for all macros, there is no runtime context to bind to. Sometimes this helps, sometimes it's a limitation. For example, interpolation at runtime can be tricky, but isn't as flexible if done with macros.


Any recommended reading?


The main site pretty good.

http://www.rebol.com/docs.html

Note, OP likely talking about Rebol 2.

Rebol 3 and Red were/are (sort of) forks...


So was AmigaOS.

Carl Sassenrath apparently got a knack for pulling that off.


> So was AmigaOS.

Absolutely.-


Red is kind of an exiting language. I'm really fond of it's whole "one language fits all" idea. I hope more visible updates come soon and I'm really looking forward to the day it becomes self hosted.


compiling a simple program takes 30 seconds:

https://github.com/red/red/issues/3412


For the record: Steven Penny (aka @svnpenn here and @89z on Github) is the author of the linked ticket, who is known for his repeated attempts at flamewar and bizzare spam campaigns against programming languages, Red included.

https://github.com/red/red/issues/3417#issuecomment-39667197...


Thanks @9214. I must have blocked it from my memory.


Funny how you didnt even try to refute the original claim, instead try to attack the person instead.


Did you notice a) that the ticket is closed, and b) it was a bad ticket to begin with? See this comment in there: https://github.com/red/red/issues/3412#issuecomment-39595136...

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.


Did you notice, that pretty much every single major language today offers static compile? C, Go, Rust, D, Nim. Why does Red think its special to not offer a static compile?


So you're changing your argument now, that's fine.

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)


argument hasnt changed. Red requires a compile of the entire runtime every single time someone wants a static compile. Even if you change one line of code, that another 30 second wait


Have your read p.1 in the message you are replying to? Red does not support static linking, that's true, but you can link to a dynamic runtime library instead, without slow recompilation times... or use the interpreter, or encap the script, or fallback on Red/System. There are options to compensate for the lack of your preferred workflow.


and people who want static compile have to wait 30 seconds to recompile, even if its one line code change


EDIT: i just read up on this. only the first time the static build is slow. later rebuilds are fast. just like every c/c++ program. the first time it has to build everything, all following times it only needs to rebuild the parts that changed.

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?


why do you need a dynamic build after every change?


As someone naive to Red myself, I just read through the 5 different compile methods mentioned in the parent comment, and while that's quite a bit more than other languages offer, it seems to offer an interesting set of tradeoffs that balance the needs of different real-world scenarios against the language design.

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.


So don't compile statically while in the dev phase, then switch and sacrifice one gigantic 30-second chunk of your life for release.

Any reason this wouldn't work?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: