I've noticed that Red shows up on HN with some regularity, and it sounds interesting. But I don't really understand where it comes from or who it's meant for. The Red / REBOL community seems more than usually self-contained, although it's possible that it's because almost everybody involved is Czech, and I am not. It seems like most of the English-language resources for Rebol were written by one guy with a thing for really long website names like withoutwritingcode.com.
REBOL was first built by Carl Sassenrath, who is probably best known for his work on the Amiga operating system. REBOL was cool, but happened when a half dozen similarly cool languages sprung up that also had the feature of being free and open source (while REBOL was proprietary and cost a little money).
REBOL had some novel ideas, and some shortcuts for some particular types of development making for strikingly concise code in some specific cases, and overall a nice design. I think it's neat that there's an OSS implementation, but I have so many other things on my todo list that I've never done more than give it a glance. I just don't see how I'd make productive use of it in the kinds of projects I do (given interop requirements I have).
Please give Red a look. It can run like Python or can be made compiled AOT to a tiny binary using a C like systems language that runs fast. You can call Red from C and possibly vice-versa (not sure bout the latter). It has an awesome REPL, amazing GUI DSL, is homoiconic like lisp for easy macros, and is OS/free. I'm not sure where this couldn't be used as it can be both super high level or very low level.
The compiler doesn't optimize at all right now, but aims for simplicity. There was an article some time back about the best switches to use for most C compilers: compile for size. It often gave some of the best performance IIRC, the rationale being better cache use on chips.
When will it optimize, or will it? I'd like to see some benchmarks on the main page for a couple of algorithms like Fibbonaci in both Red & Red System compared to a popular scripting language like Python and a popular office language like Java. I would hope Red is close to Python in speed and Red System to Java. Obviously it won't be yet, but performance is important and if it isn't a priority, I'll look elsewhere (note that I don't mean that negatively...I'm very impressed with the Red community, I just want to have my 1929 Latour with my Kobe beef riding in my personal spaceship alright ;) ). Forgive me.
I am not a profi coder, mostly a self community coordinator, but am with Rebol and Red since its beginning, so I do remember, what was said, and what not. As for the optimisation, recently a generated exe is kind of cca 4 times slower than C, if I remember correctly. With optimisations, it was said we should get into 1.5-2 territory, whereas anything below such numbers, would require quite extensive work. Please Red gurus correct me, if I remember it incorrectly ...
You're focing a lot on just one point. Many people will sacrifice ultra-optimization or even optimization itself for productivity and flexibility. There's whole industries dedicated to it.
A cheat, though, would be extracting lowest-level form to C to leverage their compilers. Lots of languages did that.
Yea, kinda see what you're saying, but not 100% at least with Nim. It has a nice high level syntax, but no REPL shell, so not quite as high level as Red. Using on Windows also requires MinGW, which is kind of hacky.
As you know, benchmarks are often fun but just as often meaningless. And premature optimization being the root of...anyway. ;)
It may come. JIT is planned. I don't know of any language that wants to be slow, and I can only speak for myself, but I think Red's goal is one of overall performance. In 1991, people told me I couldn't use VB, because it was too slow. I countered that my app would be 12-18 weeks faster than their C app. :) Still, this is 2017 and we have options.
Red won't be fast enough for everyone, or everything. But it will be faster than a lot of alternatives for many purposes. What kind of stuff do you need maximum performance for, how much of your work is that, and what are some of your real-world examples and performance criteria? I work best with concrete examples.
One of the things that initially excited me was being able to write code like Python for parsing and automating office tasks and then dropping down to RedSystem for numerical work like matrices and various algorithms and perhaps some embedded work like talking to an arduino. If it could truly do that, I'd give up needing to know 9 languages depending on what I'm doing.
Except for the embedding part, Julia is pretty good for all other purposes already, isn't it? And I say this as someone who is excited by both Red and Julia.
Julia is pretty cool,especially on the numerical side and it does have macros although I bet Red's are more powerful being homoiconic. Julia has a JIT using LLVM which is fast & neat, but it doesn't compile down to a binary exe to my knowledge.
Awesome. That's why I hope the System code is fairly fast, because compilation won't matter if it is still super slow. If y'all do a version on the JVM you get fast, but also a bloated dependency and then you're not much different than anything else with a JVM backend (Scala, Clojure, Groovy, Perl6, PicoLisp...etc). I really am excited by Red btw. Hopefully performance can be a thing at some point before 1.0. The Perl6 people released their 6.0c (basically 1.0) where the language is mostly frozen, and are now spending 90% of development time on optimizations (honestly I pulled that number out of my butt, but the ratio is in that favor) because it is so slow for most things currently. I'm not sure if that was smart as now people are thinking"I waited 15 years for this?". Overall another great language I'd happily throw away Python for, but it has some work to do before I can really use it. I hope Red doesn't fall into the same trap.
You might also want to look at ren-C (https://github.com/metaeducation/ren-c), a fork of the open sourced Rebol 3 (which isn't an active repo). It can be build with an embedded TCC so you can write C in-line for functions where you need a speed boost.
One of the nice things about Red is the low barrier of entry, for experimenting and getting a taste. If you can drop an EXE somewhere, you can run it and try things. If you can run "red -c ..." you can compile and include Red/System code.
Per Nick's comment, above, Red likely won't generate C, because that would add a dependency on a C toolchain. Red is completely self-contained, and would like to stay that way. However, you could write those tight bits in C and put them in a DLL or something, to call from Red.
It has an FFI, but no static linking to C libs at this time. Not sure if that will come, but technically it's possible, as Red's linker is written in Red/System. I'm a huge fan of Pieter Hintjens' work, and have written lots of code generators and FSM stuff, inspired by GSL and Libero.
Circa 1999 REBOL was our language of choice at our tiny company. It allowed our small team to develop faster than our competitors. We still did a ton of PHP and Java because our clients required it but lots of our internal tools were REBOL based and were quite pleasant to use and extend.
I have been following Red from a distance waiting for it to be ready for the kind of usage I want to put it through (mostly small desktop apps). I think that Red / REBOL are among the most fun languages to use for personal projects.
Is Brazilian CompSci culture relatively oriented towards embeddable languages? Lua and Céu come from there too. Might explain the adoption rate of Red.
I don't think we can say that Brazilian CompSci is oriented towards embedding. I studied at the university where Lua and Céu were created, so my personal experience is biased towards such languages and yet, I don't remember us focusing on the embedding part.
Our REBOL experience was also not related to embedding but towards expressiveness and quick prototyping.
I think I expressed myself badly, when I said "Brazilian, not Czech", I was just referring to myself, as a new non-Czech datapoint :-D, Red is not Brazilian.
Not everybody is from Czech, but I am. History of Red comes back to the Rebol era, which goes back to the Amiga era and AmigaOS author, Carl Sassenrath, who created Rebol. Czech Amiga scene had strong following, hence some ppl ended up following Carl and his Rebol. We moved on onto Red, which is strongly inspired by Rebol ...
> The Red / REBOL community seems more than usually self-contained, although it's possible that it's because almost everybody involved is Czech, and I am not.
REBOL being proprietary when the big F/OSS scripting languages were taking off in popularity was probably a problem for mindshare and community breadth.
This is definitely a neat release. Red seems to be coming along great, and am interested in what a 1.0 release might look like. Checking their "Roadmap" they have some very interesting (great?) goals. They seem to be heading towards a sort-of "runtime purity" by (at least aiming for) targeting:
- Native (bridging to Obj-C)
- JVM
- CLR
While also supporting shared objects so my assumption is that dynamically linking is possible.
On top of this it looks like they want to support a sort-of wxWidgets-like GUI programming (which I personally believe to be the correct approach to GUI abstractions). Backends they aim to support:
- Windows (done)
- GTK+
- macOS
- iOS
- Android
This reminds me of the approach a lot of JVM focused languages are taking like Clojure that support the CLR, JVM, Node and Web Browser.
I guess the obvious questions to ask would be:
1. Any reason for not wanting to target WebAssembly/JavaScript (and in conjunction node.js [I understand that this isn't trivial])?
2. Any reason targeting QT isn't on the roadmap? [targets for KDE, Sailfish, ect..]
3. Any reason wxWidgets wasn't a great choice as a foundation? (I believe they have a C API last I looked)
4. Is there or will there be an API for creating custom languages that can target/leverage Red's infrastructure? (basically a Red version/wrapper for flex/bison)
Finally, adding support for Erlang nodes should be fairly trivial if it was a wrapper to the C Node API, but it could also be implemented via a pure Red implementation.
tl;dr I'm interested to see how Red will evolve further not necessarily because the syntax intrigues me, but because of the goals the team have set for themselves as far as polymorphic runtimes go.
> 1. Any reason for not wanting to target WebAssembly/JavaScript (and in conjunction node.js [I understand that this isn't trivial])?
Wasm will likely be the browser target.
> 2. Any reason targeting QT isn't on the roadmap? [targets for KDE, Sailfish, ect..]
They wanted to go native to start. QT is GPL licensed. Not a good fit for Red. Their "small" installer, which downloads the big stuff, is 18M. Red, with self-contained toolchain and cross compiler + GUI, is 1MB.
> 3. Any reason wxWidgets wasn't a great choice as a foundation? (I believe they have a C API last I looked)
Targeted at C++, and also very large.
> 4. Is there or will there be an API for creating custom languages that can target/leverage Red's infrastructure? (basically a Red version/wrapper for flex/bison)
You can use libRed, which makes Red available as a DLL you can call into from other langs, like C. See http://www.red-lang.org/ where a couple GIFs show integration with VBA and Excel even.
Ultimately, the decision not to use something comes from value added and available resources. Team Red is small, and has to pick their battles carefully.
I've never seen a language with such a variety of built-in data types (e.g. coordinates, tags, email, url, issues). There's support for IPv4 numbers as a base type (tuples) but I can't tell if there's support for IPv6, which shows the trouble with this approach for the language maintainers.
What does a type being built-in do for you extra? In ES6 you can define a template string builder which you could name, for instance, ipv4, and then when you want an IPv4 address literal you say
ipv4`192.168.0.1`
and get your object. Are there other benefits besides a literal syntax? (Not to slag on Red. One advantage I can see is avoiding the call at runtime to the ipv4 function.)
I'll add to my reply, because this is a really good question.
Red doesn't have all types in place yet (e.g. date! is coming, and maybe an @ref type, among others), but can still load the following:
at 10:00 send gregg@host.dom a link to http://red-lang.org (216.239.32.21)
delete %/c/temp/junk.dat
assign #DECAFBAD-7337 to John
make the main window 800x600 with a color of 255.0.0
answer: yes
Here's a quick console session showing what types it found:
>> blk: [ at 10:00 send gregg@host.dom a link to http://red-lang.org (216.239.32.21)
[ delete %/c/temp/junk.dat
[ assign #DECAFBAD-7337 to John
[ make the main window 800x600 with a color of 255.0.0
[ answer: yes
[ ]
== [at 10:00:00 send gregg@host.dom a link to http://red-lang.org (216.239.32.21)
delete %/c/temp/junk.dat
>> unique collect [foreach val blk [keep type? val]]
== [word! time! email! url! paren! file! issue! pair! tuple! set-word!]
And you can parse at that level:
>> parse blk [
[ some [
[ 'window set val pair! (print ["size:" val])
[ | 'assign set val issue! (print ["issue:" val])
[ | 'link 'to set val url! (print ["link:" val])
[ | skip
[ ]
[ ]
link: http://red-lang.org
issue: DECAFBAD-7337
size: 800x600
Of course, you could do something similar in ES6. If you use template literals, your data might look like this:
at time`10:00` send email`gregg@host.dom` a link to url`http://red-lang.org` paren`(ipv4`216.239.32.21`)`
delete file`%/c/temp/junk.dat`
assign issue`#DECAFBAD-7337` to John
make the main window pair`800x600` with a color of color`255.0.0`
name`answer:` bool`yes`
That does look handy! I guess there must be a tradeoff in having your text default to meaning plain words if you mess up the syntax? Versus hopefully getting an error in the ES6 case.
You can always get errors of course. The new `load/trap` feature gives you more flexibility in that area, but there are limits as with anything. Pretty handy for CLIs, though, when you expect your audience to know what "syntax" even means. :)
Yup. We often write code like normal programmers, but sometimes we do build up vocabularies more, even when not using `parse` to write DSLs.
"Red or REBOL" = Redbol (sounds like Red Bull) :) And where Perl has Mongers, Ruby has Rubyists, Python has Pythonistas, and Rebol has Rebolers, Red has Reducers.
Ha, Reducers is a good term, considering: the goals of Red (reducing complexity being one), the small size of Red (and REBOL) programs that get non-trivial things done, and finally the size of the software itself (the interpreter - and also compiler in the case of Red). Even the small EXE sizes, in fact (though I've only created EXEs for small programs so far, with it).
One of the key reasons for having a lot of literal forms is because REBOL was designed as a messaging language. You can think of it as a data format as much as anything. Template literals in ES6 help with DSL support, which is fundamental in Red's design. It doesn't mean you can just include anything in Red, but the wide array of native forms lets you build a lot of embedded DSLs without resorting to string parsing. Being able to parse at the block level (i.e. datatype level) is really nice.
A couple other new features make dealing with non-loadable input easier too. You can use macros to pre-process data, trap errors that `load` triggers and still get back a block of values, or spec some simple rules in `system/lexer/pre-load`. That's another way we might deal with IPv6 values.
Yes, a message format. What I would add is, that today ppl are using JSON, not realising, that it is de-facto a Rebol, or at least strongly inspired by Rebol. Well - who wants to use cryptic formats anyway, right? :-)
The tuple! type supports 3-12 segments, but only 0-255 in each segment, which is a byte. So it's used for colors, IPv4, and can be stretched for custom purposes. IPv6 doesn't have a literal form, though it's been discussed. One of the problems is that lexical space is tight and supporting it specifically may lead to ambiguity with time! values. Also, the colon is an important delimiting character, which makes having hex coded value ambiguous as well.
>the colon is an important delimiting character, which makes having hex coded value ambiguous as well
In IPv6 or in Red, you mean?
In IPv6 the colons are there for convenience only, with the rule being that leading zeros can be omitted and that two or more consecutive groups of all zeros can be replaced with ::. You can only have one instance of :: otherwise it would be ambiguous.
For example, the IPv6 address ::1 is actually 0000:0000:0000:0000:0000:0000:0000:0001.
Likewise, 2a03:2880:fffe:c:face:b00c:0:35 is actually 2a03:2880:fffe:000c:face:b00c:0000:0035.
Once an IPv6 address has been expanded to it's full non-abbreviated form you can safely strip it of colons and use the resulting hexadecimal value to uniquely represent that address.
If you were talking about colons in Red and not in IPv6, disregard what I said.
Language is still in active and early development, so it could be added. Having primitive types for a lot of things makes for some very short, yet still easy to read code.
The Red website has it somewhere, but they're focusing on the Lang and not the site at the moment, so it might be hard to find. I think the Rebol website (successor language that is mostly compatible although interpreted only) should have a lot of those.
I think Red is a language to watch. It has a lot of potential. But my understanding is that Linux support is still immature. Currently the focus is Windows. Is that a correct assessment?
So far Linux lacking only GUI backend support, everything else should work fine. You can still play with guy crosscompiling (as easy as `red -t Windows file.red`) and running on Wine, while GTK backend is in progress
Sadly, the GUI stuff is what has me most excited for playing with in in private projects ;)
But I can wait. It's open source and free, gift horse mouth and all that. Can't fault the developers for prioritising either areas for which they currently can get funding, or scratching itches in their own dev environment.
GUI screenshots are more exciting than console screenshots. :) Red opted to do Windows GUI first, and also to use native widgets on all platforms. A full native GUI may come later, but that's why the current look of promo material.
Yea, using a simple switch to compile tiny native executables for a ton of platforms is a huge draw. Not having to walk a non-coworker through a python install who doesn't want python on their computer will be nice.
I was hoping someone was bringing back corewar. The game was played in a language called Red Code. Pretty fun game for it's time.
https://en.m.wikipedia.org/wiki/Core_War
I know a lot of you may like case insensitive languages, but it just feels weird for me. And there is the "nim" language which makes no distinction between CamelCase and snake_case.
> At least it doesn't force any casing on you, as some languages do.
I'm not convinced that is actually a good thing. It really annoys me when two libraries for the same language use different naming conventions, and so far I haven't had any trouble with the strict casing rules in Haskell, or the casing conventions in Rust where the compiler emits warnings when you don't follow them (that you can disable with an annotation if you really need to).
We, as programmers, will never convince anyone that our preferences are right for everyone else, even when there are strong technical arguments. In this case (pun intended), it's subjective. A lot of it is what we get used to.
If anyone wants to try out Red, I'd recommend setting up the Red plugin for Visual Studio Code, it's not essential (you can code effectively without it) but it does do the basics very well IMO.
Rebol looks interesting; what does Red do for memory management? Is it garbage collected or does it do reference counting? If it is reference counted then what does it do with circular references?
i did take a glance at the documentation but did not find the answer to this question - without knowing how the thing allocates memory it is sort of pointless to invest time into learning the language...
The problem with a lot of Red's features is that core language/runtime features are added to the language last.
- GC is added after a lot of language is already there.
- Actors are planned to be added _after_ I/O, and _after_ GC, and _after_ all the GUI capabilities (Trello board lists "figure out how to rewrite event loop with actors")
- A lot of FFI is already there, so GC, and actors are coming after FFI.
These are not features you add on top of a language and hope they magically work. Actors directly affect how I/O and GC work. GC should be very aware of how FFI works. etc.etc.etc.
A lot of these issues are dismissed by the core team as "it's not difficult to write a GC, we have it in a branch somewhere" (referring to a naïve mark-and sweep stop-the-world GC).
> Why do you think it's pointless to learn without knowing how it handles memory?
I think that a non trivial program will have to employ dynamic memory allocation, so if it is not obvious how to do that then it will not be possible to write a complex program. Learning a language that can handle only simple cases may have some uses, but you already have existing tools for that.
Got it. Red does manage memory for you, but no GC yet so can't do long-running procs without care. I've written small Red apps that used 800MB, loading a large dataset. Totally stable but, again, maybe wait for GC if you're going to grind a lot.
Red's complete toolchain, compiler, linker, etc. are bootstrapped entirely in Rebol2. Red is more capable than R2 (though alpha, with features pending), so it's safe to expect that it can handle more than simple cases. In fact, one of the reasons Red 1 was implemented in R2 was to prove that Red would be able to self host. It's possible most of the current toolchain would even work at 1.0, but the team has learned a lot while building this version, and has said on many occasions that Red 2 will only keep the best bits.
All that said, even if you never use it in production, it's a great language to play with and expand your thinking, because it's so different.
I'm waiting for a "Red in Action" book or the like. What I've seen in the Rebol examples hasn't helped me a ton with understanding the Parse dialect...etc.
