I'm always excited for a new Red release. I'm glad they're taking time to get the GUI DSL right for 10 platforms, but I hope it doesn't come at the detriment of enhancements to Red/System, Multi-Core, Concurrency, and all the other promised goodies. The thing badly needed at this point I think is better doc. I know it is ~95% compatible with REBOL, but honestly the REBOL doc is very basic. It shows you how to do a lot of neat things with the built in DSLs, but nowhere and i mean anywhere does it show you in any detail how to implement your own DSL, while you frequently hear about how powerful the dialects are. I'm still super pumped about this language and am thrilled for each new release.
I also tried to learn the "PARSE dialect" (the DSL coding mechanism of REBOL/Red), as this is what's often claimed to be the crucial differentiating factor (the "main idea") of REBOL/Red - but I failed, because of what OP mentions. The REBOL docs feel to me more like an example-based guide, than a solid RTFM-grade manual. I find such a guide OK and valuable as a tutorial, a starting point, and to teach idioms and mindset; but then I need a reference manual to clarify all details and fully explore the topic. Also read some third-party articles on PARSE, but none of them were comprehensive enough (AFAIR, mostly being tutorial-like too). Lua and Go do it well in my opinion - they both provide a solid tutorial-like experience, but then a full-blown, well written reference manual too.
There are two third-party reference-like (but non-authoritative) documentations that I know of [0][1]. A Red reference documentation for Parse will be available later this year.
Thanks Nenad! :) The links indeed look interesting, at least at a first glance, though it seems not quite clear to me which keywords are R2 vs. R3 (proposals?) vs. Red, especially in the link marked as [1]. Still, at least that's something, will certainly be very useful if I try to understand PARSE again at some point in future. And I'm very happy to hear you're planning some more comprehensive docs for Red!
Good to see I'm not the only one that has trouble transitioning from playing with Rebol to actually using it in non-trivial programs. Sure they have a form of OO, but I'm not sure if it is really idiomatic to use it a bunch or if coding should be more like C. I'm prepared for Red zealotry though if they can provide the experience that they're aiming for along with good doc.
Red is not dogmatic about objects, but there is certainly a clear line between idiomatic Red and other code, in a more general sense. That is, you can use objects, or not, and write idiomatic Red. It's all in how you use them. They are most useful in terms of creating namespaces (contexts). When you don't need that, blocks are the more common type to use. There is also a `map!` type, which is a useful type because it has a literal form, like blocks. Of the 3 (block, object, map), only blocks are directly parseable, but objects and maps support reflection.
Thanks again. As a beginner in this language family it would be helpful to see the doc go over this with some examples clarifying your points at some point when y'all are closer to 1.0. I'm probably not the only one who wouldn't know how to architect their code without overusing classes.
I'll check these out, but why doesn't Carl have something like this on the official site in a prominent place? You can't spend 5 minutes on a lisp forum without hearing of and seeing macros everywhere. Why not Rebol & Red? I'm getting a little off topic, but hope Red doesn't make this same mistake.
Making it prominent will appeal to a different target audience. Rebol is beginner friendly, but dialects (as easy as it makes them) are an advanced topic. We'll try to provide good docs and examples for Red, though, because it is a key feature that sets it apart.
Never thought Carl might have done that for marketing reasons. Thanks for the insight. I look forward to a write-up on Red dialects :) than. Hopefully, I can start contributing to the project some once I get a better grasp.
Am I reading this right? A single binary, less than 1mb in size, that handles GC and cross compiles? Color me impressed. Looking at platforms, does it not do 64 bit?
You're correct. It's crazy what you can do when you don't bundle 8 zillion MB of C in your install. Rebol is the original parent language, but it doesn't have a system language to compile to, just a < 5 MB interpreter that you could do a lot with. Neat little languages. The creator wanted to take Rebol and write a version that would be the first true "Full Stack" language covering everything from desktop GUI to building OS, to highly advanced parsing, to robotics. If you google it, there is a nice interview with Red's primary author Nenad Rackocevic (forgive spelling) that is from ~2015, but still should be accurate.
>> just a < 5 MB interpreter that you could do a lot with
Just to note that Rebol 2 is below 1 MB. Depending on platform, Core is normally below 300K and View is around 600-800K - http://www.rebol.com/downloads.html
This Rebol 3 size will shrink. Currently there is development on build & extension process which will help. NB. There's been a big refactoring/redesign of the Rebol 3 interpreter in last couple of years so there maybe (still) some artefacts from many forks/merging of codebase that could also be shaken out.
I'd rather have misspelled information than not have it.
Some folks might be on a mobile device with an interface that makes it difficult to switch to another window. Or perhaps they are offline when they're writing it. Or perhaps they have mobility / accessibility issues that makes switching a challenge. Those are off the top of my head.
To my mind, worrying about someone's spelling when I can understand them perfectly is one of those "life's too short" issues, speeking personaly.
>Some folks might be on a mobile device with an interface that makes it difficult to switch to another window. Or perhaps they are offline when they're writing it. Or perhaps they have mobility / accessibility issues that makes switching a challenge. Those are off the top of my head.
There's also momentum. They want to go write a quick comment and type their thoughts as they come -- not stop and Google things.
This is certainly how I am sometimes. I will stop to check things, but it breaks the flow. And, as comments here point out, docs are a big issue. What isn't always clear is how much effort they take to create. With a small team, it's a constant struggle for where to allocate resources. Right now, Red's priorities are based on deliverable functionality.
Thanks Greg! That is well understood and fine by me. I just don't want to see Red's doc to end up like Rebol's. Honestly, it is probably a non-trivial factor for why it never took off.
The old 32-bit K2 (K language) had a superfast ACID DB, GUI, GC, no dependencies (but also no compilter) and was 250K, so 4 independent platforms would still fit in under 1MB; Arthur is now working on KPARC, which has no compiler but does boot on metal and includes GUI, editor, db, filesystem, network, and a lot more, e.g. this http://kparc.com/edit.k is the implementation of native nano-style GUI editor. ; Last I heard, it was still <500KB.
Right now, it only compiles to 32 bit binaries (which can run on both 32 and 64 bit OS).
64 bit support will come after the compiler is bootstrapped.
> and cross compiles
Yup, easy cross compilation. You do not need different cross compilers for different platforms a la llvm and gcc, a single 1 mb binary can produce binaries for all supported platforms.
I looked over the code to guage how big this 32-bit problem is. It's going to be a lot of work. 32-bit is hardcoded everywhere. Compiler, linker, libc calls.
So, on one hand, there's massive cross-platform support. On the other hand, those platforms are all obsolete, or about to be. Even the mobile and embedded ones have all gone 64-bit.
Maybe backwards compatibility will be maintained for a few years. But it ruins the embed-red-in-C story already.
The current compiler was written with the aim of quick development till 1.0 is reached (because in the initial development phase, there are obviously many other important things to focus on). So, yeah the toolchain has some issues, eg. there are very few (if any) optimizations. Also, only 32 bit is supported.
There are AFAIK no plans to add 64 bit support before bootstrapping phase because the current toolchain architecture isn't that great and will be heavily improved during 1.x cycle.
64 bit processors (and their OS platforms) will retain backwards compatibility to 32 bit apps for the forseeable future. There are too many situations where 32 bit apps are better for that not to be the case (smaller binary size and better cache performance).
For mobile and desktop, sure 32 bit is fading, but embedded 32 bit is so far from obsolete. I don't know how you can even claim that when even 8 bit platforms still have a huge market share.
ARM cortex-M (32 bit) has only recently been able to chip away at 8 bit platforms and gain major use
Yes, but the embedded platforms that are interesting for high-level scripting are mostly phones. Worse than desktops, they won't bother with 32-bit compatibility layers.
Using the other meaning of embedded (I embedded a Lua script in my C application), compatibility libraries don't help. It simply won't link.
> No timeframe until we find someone to work on it. Though, we should be presenting Red at the GNOME global conf in China on October, so I hope we can find someone motivated and skilled enough there to work on it.
Very Cool! I've got to try this out! I'm definitely picking up a bit of a Tcl vibe here, which is another language I've been wanting to try out. Especially with the integrated GUI toolkit, it's giving me some Tk vibes as well.
Does anyone know if there was any direct inspirational link from Tcl to Red/Rebol, or was it just by the nature of the idea of making an extensible langauge suitable for making lots of DSLs in?
Rebol/Red (a.k.a. Redbol) languages inherit from Lisp, Forth, and Logo, along with Self for the object model. Tcl was not an influence as far as I know. There will certainly be other minor influences, as Sassenrath, Ousterhout, and Cowlishaw were all important designers in that era.
Android GUI support is planned for 0.6.5. iOS support is planned but not started. Can get some sense of the maturity of different features by looking at the feature and version roadmaps:
It is possible to compile console apps that run on Android right now, though AFAIR this feature isn't fully stable yet.
It's also worth noting that Red can be used as an embedded language. So for example, after 0.6.5 is released, you could have an Android app where the GUI was written in Red, but code managing phone features like GPS could be written in another language.
As for supporting mobile features directly, I imagine some of this will be managed by libraries rather than baked into the language runtime. Worth noting that the module system is planned for 0.8.0. However, it should be possible to write feature rich mobile apps long before then.
> Will Red get direct access to Android's (and IOS later) camera, location, gyroscope, etc features?
> Absolutely, our GUI engine already features a camera widget (in our Windows backend). The work on Android backend in 0.6.x version will bring wrappers to all the common hardware features.
So yeah, I guess the plan would be to support all mobile features.
When Rebol first appeared it reminded me very much of new language that appear at the same time called Curl (not be confused with ubiquitous HTTP tool).
The similarity, goals, and timing of release of both languages is in interesting convergence. Curl unfortunately tried to go to commercial and died a quick death. I'm glad Rebol and now Red are doing well.
I got to know about the Curl language and tried it out some when it came out. (IIRC Tim Berners-Lee was involved with it in some way, and I later read that the tech was sold to some Japanese company). They had an IDE called Curl Surge (IIRC). I thought it was an interesting and potentially useful language, specially for web apps.
But (with the caveat that I did not try Curl out for long), not sure how similar Curl was to Rebol. I thought Curl was a bit like Lisp, so AFAIK the only / main similarity with Rebol might have been homoiconicity (if I'm right about them both having that property). But could be wrong.
The main one was that having a single language was a win, compared to mixing 6 or 7 of them, and their associated cognitive overhead. Red expands this in both directions, with Red/System as the low level dialect and metaprogramming at the highest level.
Yes, absolutely. Red has a `parse` function, that uses EBNF-like rules, but someone has written a nice regex translator if you need that bit. It's also possible to write a nice AWK-like dialect that handles things at a higher level. I've done that in the past. One of the current limitations is that the I/O model is simple, and there is no GC yet. Those will come in the relatively near future, but if you have large files, or need long running processes, it will be more work for a while. Still doable, just not as easy.
