131–135 of 135 posts
Earlier quoted context omitted.
Even without the new spiffs, I still don't see the point of DSLs. From where I sit, I see exactly zero problems where I think that new syntax is what I need to be able to write a solution.
Lisps don't support OO, concurrency like Go, or type checking but you can write a DSLs for them. Not useful? How about a rules engine?
The website looks like 2013 and much of the content is as well. There's a GitHub repo that I couldn't find from the website: https://github.com/red/red
The website links to GitHub with the usual logo, in the right hand column. The website has posts from 2025: https://www.red-lang.org/2025/04/multiple-monitors-support.h... Unless you mean the theme, thats probably just a standard Google Blogger/Blogspot theme, which has been around for 25 years. https://en.wikipedia.org/wiki/Blogger_(service)
Red is more different than you may think, just by looking at it. It is designed such that things that look familiar may work very differently under the hood. That's good for making people comfortable, but also means you can't judge a book completely by its cover.
Red is a data format first. That's very Lisp-like, but Red goes further with the large number of datatypes that have a lexical form. e.g. email, url, pair, point, file, date, time, money, etc. Where Lisp* says code is data and data is code, we tend to say "Everything is data until it is evaluated." Rebol was only interpreted, but Red (not all Red however, as some things are too dynamic and require JiT, which we don't have yet) can be compiled.
Red compiles to Red/System (R/S) code. R/S is a static dialect (DSL) of Red, which compiles directly to machine code. No external compiler or C code gen. So you can write DSLs in Red, and those DSLs can be higher or lower level. We call this Metal to Meta programming. Compile a small R/S program, and you will see it's fast, and fully standalone. Compile Red in Dev mode, where the runtime isn't rebuilt, and it's also fast (after the first time). Compile in encap mode and...more to explain. Compile for release and it takes time, but gives you a standalone EXE. It's slow for a number of reasons. Just the current state of things. Compilation speed has not been a priority.
On APIs vs DSLs, a key distinction for me is that API don't have a natural way to enforce the order of operations. That's where a grammar adds value. And because Red is often self-consuming data, the ability to write grammars (`parse` rules) that are very BNF/PEG like, it makes data handling quite powerful. I also think it's easier than most other systems, but that's me, and I've been in the Redbol (Red+Rebol) world for a long time. Two related notes on that. 1) `parse` is, itself a dialect of Red. 2) You can parse not only at the character/string level, but at the value and datatype level, including literal values and typesets. Typesets are a way to express datatypes that are related. e.g. the `number!` typeset matches `[integer! float! percent!]` types. All that said, Red is a multi-paradigm language, including functional (though not pure functional), so you can absolutely build things in an OOP/lib/API manner if you prefer.
Infix came up, and the model is simple. Infix ops have a higher precedence than func calls, but there is no other operator precedence. Strictly left to right for ops. And, yes, operators are a datatype and you can make your own from most 2-arity funcs.
Func args are not enclosed in parens or brackets. This is a fundamental aspect that takes some getting used to. Once you do, at least from what I've seen through the years, it feels natural. We call this "free ranging evaluation" and it's a powerful aspect of Red. It also plays into dialect design. Red is sufficiently flexible that you could hack around this if you want, but then you're fighting the language, rather than working with it.
Red is high level and garbage collected, but it is not "safe" by some standards. Mutability is the default, values are strongly typed but variables are not, you can mix Red and Red/System pretty much however you want, and R/S is basically a C-level language. We talk about these tradeoffs a lot, and how to find a balance. Nothing comes for free.
One of the main dialects in Red, along with `parse`, is the `VID Visual Interface Dialect`. This is how you describe GUIs for Red's cross platform GUI system. You could also build a tree of faces manually, or write your own GUI dialect or API.
Another cross-platform note. Yes, we are 32-bit only at the moment. It hurts us as much as it hurts you. But Red can cross compile from and to any system it runs on. No other software or compilers needed; just a command line switch.
One of our primary goals is to "fight software complexity". That doesn't mean Red will look like C, or JS, or Python. It doesn't mean any one thing. It means a lot of things working in concert. We also hope to keep Red small and easy to set up. Today you can still just drop the EXE somewhere and go. The toolchain (interpreter+compiler) is ~1.5M and the REPLs (text mode and GUI mode, separately) are just over ~2M. We may offer more options at some point, ideas like using LLVM come up a lot. While they solve some problems, they create others. So far, the costs have been deemed unacceptable, and we don't have any showstoppers (other than time). But since Red is open source, with a permissive license...
Happy Reducing!