Languages that encourage making DSLs are a two-edged sword. On the one hand, you get to make a language that is more clear and fine-tuned to your use-case. On the other, you have an ad-hoc language with no support that you have to maintain along with the documentation (considering that you can't expect anyone else to know the DSL ahead of time). As I've gotten older, I've determined that well-designed APIs in a well-known language are a better alternative to DSLs.
I’m right there with you. Modern languages have such a plethora of tooling available that DSLs and any API approaching a DSL have this massive gap unless they really embrace whatever patterns the host language’s tooling enables.
Not long ago, i had to work with a coworker’s mini language and function runner engine, which was basically a mini programming language. Except without a debugger or type checker or stack traces or any of the other million niceties we’d have had if we just used the host language to execute things ‘natively.’
That said, while the level of tooling for big languages goes up, the bar for creating yesteryear’s tooling is going down, with all the LSP tooling we have now, for example. Maybe someday we’ll get languages with tools where libraries have nice tooling without crazy dev effort, and then we’ll change our tune on DSLs.
Because they are really really difficult to get right almost as difficult as building a new language. But when they work well they can be a real boost.
Sometimes you want a specific limited subset of the parent language, especially when you don't want to expose a huge possibility space to non technical users. Exposing only a limited subset can also be helpful to sandbox for security reasons.
Even DSLs of huge and successful projects are more often than not bad. As a rule if you think that you can create a better query language than SQL, please spare us. JQL, Elastic Query DSL, KQL... Don't.
It has been interesting to watch the Clojure community’s take on DSLs over time. Clojure is a Lisp, and Lisps are notorious for inventing DSLs, particularly after PG’s various papers promoted that as a superpower of sorts. Clojure has gone the other direction and, while it supports macros, it generally discourages their use unless you’ve tried everything else first. But it still encourages DSLs built from the native Clojure data structures. So, for instance Hiccup for HTML generation.
The discouragement of macros I think is a knee-jerk reaction. Build around data structures and functions first, and then use the thinnest macros around that can be quite maintainable.
Kind of, except that a non-DSL API doesn't create any new syntax. Which means that you get to keep all sorts of quality-of-life tools like syntax highlighting and correctness checking in the editor, autoformatting, possibly some amount of linting, etc.
A few years ago I revisited Racket after a long hiatus, and that was maybe the biggest thing I noticed. I really don't like syntax macros as much as I did back in the day. Once I decide to use `define-syntax` I've then got to decide whether I also want to wade into dealing with also implementing a syntax colorer or an indenter as part of my #lang. And if I do decide to do that, then I've got a bunch more work, and am also probably committing to working in DrRacket (otherwise I'd rather stay in emacs) because that's the only editor that supports those features, and it just turns into a whole quagmire.
And it's arguably even worse outside of Racket, where I might have to implement a whole language server and editor plugin to accomplish the same.
Versus, if I can do what I need to do with a reasonably tidy API, then I can get those quality of life things without all the extra maintenance burden.
None of this was a big deal 20 years ago. My expectations were different back then, because I hadn't been spoiled by things like the language server protocol and everyone (finally) agreeing that autoformatting is a Good Thing.
Conversely, Ruby is often seen as facilitating DSL's, but none of it changes syntax, because the syntax as-is is flexible enough that redefining methods is sufficient. But everything still abides by the same syntactical rules.
The more orthogonal or flexible the language is, the less there tends to be a distinction between redefining syntactical elements and defining functions or methods.
> Kind of, except that a non-DSL API doesn't create any new syntax.
Internal DSLs are always (by definition) valid code in the host language; external DSL, where parsing and interpretation or compilation to executable code for raw text code in the DSL are implemented in the host language, are all new syntax, but “languages that encourage making DSL” are usually ones that are favored for internal, not external, DSLs.
I think that "internal DSL" is what the grandparent poster meant by API, so I just went with that.
I think the internal/external terminology might be kind of outdated, anyway? I think this might be the first time I've encountered it in the wild in over 10 years.
> I think that "internal DSL" is what the grandparent poster meant by API, so I just went with that.
When people talk about REBOL/Red (or Ruby or Lisps) encouraging making DSLs, they are referring to internal DSLs. In Ruby, these are just APIs consisting of normal objects and methods, in Lisps they often involve macro calls, which may or may not correspond to what people mean by an API, and in REBOL/Red the design of the language is such that “normal” functions can do things that would take macros in Lisp.
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.
I used to feel that way. I’m still not a convert, but now I’ve seen a lot more complexity papered over by a nice DSL.
Standard math syntax is a DSL. I understand math a lot more quickly than I understand the same thing written in 20 lines of code.
I think the language we use to express ourselves influence the quality of the product. If your language encapsulates complexity, then you can build more complicated things.
I’m not arguing in favor of specific (“pointless”) DSLs, but there’s a nice paper about making a video editing language in Racket [1] that makes a DSL seem pretty convincing.
The protocol buffer / grpc definition language is another great example of where a DSL can shine. Especially if you compare it to efforts to accomplish basically the same task using pre-existing languages, such as OpenAPI (JSON) and WCF (XML).
You could write DSLs for them, but you could just as easily do it within the existing syntax. Which is exactly how all the popular lisp implementations of OO, concurrency and type checking work in practice.
Many of them do use macros. But that's not about creating a special language; that's about moving expensive computations and checks that can be done statically to compile time where they belong.
Where, in a real program, `domain` would be defined in a "standard library of constructions" that you can just import and re-use in more complicated regexes.
Something like this can be implemented in any language with operator overloading, no DSL required. Without operator overloading, the syntax would be a bit more awkward, but still nicer than the current regexp madness.
I don't quite understand where regex gets its reputation from. I think that once you remember the meaning of the operators, it's not too bad. (And the concise syntax is actually very helpful.)
I get that the meaning of the operators is not clear unless you're already familiar with regex, but neither is the meaning of !, ?, %, &, |, ^, ~, &&, ||, <<, >>, *, //, &, ++ (prefix), ++ (postfix), and so on. You learn these because you need them once, and then they're burned into your mind forever. Regex was similar for me.
I think regex gets some of its hate from people writing painfully complex matchers. 99% of my day to day regex use is simpler string searches on the command line or in my editor. I’m really happy I took the time to learn the syntax (spent about a week on it around 15 years ago) because now it doesn’t get in my way.
Regex syntax helps you understand what a regex does, not necessarily why it does it.
You can't decompose it into parts, you can't give those parts human-friendly names, you can't re-use parts in other regexes, you can't (easily) write functions that return or manipulate regexes (like that "list with separator" function shown above).
There’s really nothing about this that couldn’t be expressed just as clearly in a more general API though, even in C, IMO. Building it into the syntax is a little weird to me.
Fair point, though I learned regexes a long time ago, so that they weren't on my "problems that I can solve with new syntax" list, but instead on the "syntax that's already there" list.
An API creates its own ad hoc rules too. They just don't change the grammar.
In languages where the grammar is sufficiently flexible, the distinction all but disappears, but even in languages where the grammar is rigid and API's stand out like a sore thumb, the API itself still creates a new rule-set that you need to learn.
You can choose to not call that a new language all you want, but the cognitive load is still there.
An API (as people usually mean by it, anyway…) is really just a simple grammar for the creation and manipulation of objects in the system. Those objects still have types and properties just like any other object, but they tend to be implicit and unreliable. A good DSL is just a more abstract and implicitly verb-oriented API. For example, Lua DSLs can resemble something almost like a sort of typed or tagged DDL. Translating that into an “API” just adds more clumsy legwork to achieve the same outcome.
Agreed - I was tempted to make the same claim that it is still a grammar, but decided against it as I suspected it'd get in the way of making the point. You're 100% right you can write a grammar for an API as well, or can consider the API definition it self as creating a grammar.
This might be one of the rare times it's worth it. The C# team alread has the experience and tooling to maintain a language. Maintaining a DSL might be a reasonable choice for them.
It's rarely a good idea for app or library devs to make a similar decision.
Yes, this reminds me of meta-programming in languages like Python, it's useful if you want to create a framework like Django, but if you work on products, chances are good you should not use it.
There are plenty of places where it makes more sense to use DSLs (or where they’re flat-out required). SQL and regex both spring to mind. Pretty much any HTML templating language is simpler to use than concatenation a bunch of strings together. JSX is usually easier read than directly calling React functions directly. A line of a shell script can be much nicer (and more portable) than 20 lines of a more general purpose language.
Those are things that spring to mind that I think are unequivocally DSLs, but if you’re willing to consider markup languages as DSLs, the list could get a lot longer.
Most people think of DSLs as a language you can create within a language. All the things you named are either entire languages themselves like HTML, SQL, and the shell family, or formal extensions of existing languages like JSX. A DSL would be something you could create inside JS tagged literals or Ruby.
No, an API is a contract. Just like an object or a class or a structure is not a DSL.
None of these modify the syntax or keywords of the language used to implement them, and only objects and classes actually have the ability to override operators.
Just grouping things together in a particular order and giving the group a name does not make a DSL.
An API is an interface, metaprogramming is a technique for building such interfaces by treating code as data. They aren't interchangeable concepts.
Metaprogramming comes in handy when ordinary programming results in a lot of complex, hence unmaintainable, code or can't achieve something due to how the language is implemented. It can vastly simplify how you express application logic, e.g. when interfacing with foreign programming languages such as SQL or generating code from data.
Any sane metaprogramming regime allows you to do something like macro expansion, i.e. look at the code the metaprogramming is compiled into in the current context.
this is a very important lesson. I remember the frustration of dealing with the Gradle and whatever was the name of the DSL used by Fastlane. Gradle especially kept changing so documentation was never really useful and there was zero help from the tooling
That's mostly my experience with ruby, too: you can type anything, don't worry about it!
I wanted to mention that Gradle since I think about version 7 supports mostly static typing via Kotlin but regrettably it's lipstick on a pig since almost inevitably one needs to interact with the Groovy side of the house and then all bets are off
And at least the last time I used it in anger (which was, granted, perhaps double digit years ago), the docs started out with and loudly proclaimed "here's how you write your own tasks!" Wait, what? I want to have a build system do at least the 80% case with minimal/zero work; why am I jumping right in to my bespoke needs?
Not sure if this was just bad doc, or the tool actually didn't do the 80% very well then or what, but it's stuck with me.
I wouldn't say that. It's just its trivial to make DSLs in languages like the various lisps (common lisp, racket, chez scheme...etc).
That's usually what people complain about (besides the parenthesis) in that it's easy to not be very disciplined.
Lisp is homoiconic, so there isn't really a distinction between programs and data. For example, a snippet of code like a for-loop iterating through a list is also a list that can be inspected and modified. Or something along those lines (there's an XKCD comic that captures the spirit where the person says "it's all CARs" as in lisp you can build everything from CAR, CDR, and CONS I think). You'll have to dig into that on your own. The terms are historically relevant, but seem antiquated now. I've never really understood macros (compile or runtime ones) all that well though, so hopefully someone else in the comics can clarify my mumbo jumbo.
I've been thinking about this a lot. DSLs solve an important problem, but they do it in the wrong direction.
It's impossible to write objective fact. Everything we write is subjected to the context it is expressed in, including the grammar that we use to write it. A DSL accommodates this by letting you make a new grammar on the fly. The trouble is, this doesn't help us get out of the context we are writing in already: it only lets us enter a new one that is nested inside.
So what if we could actually get out? What if we could write from outside of the context we are writing? That's the idea I'm working on. I think it's possible, but it's such an abstract idea that it's tricky to get a handle on.
I don't remember how I found it, but REBOL was one of the first programming languages I learned around 25 years ago. Most of my personal projects are still written in it.
I wrote a small app in REBOL once, just too automate some stuff for some managers in a job about 20 years ago. It's quite nice, but I don't think I'd want to write anything significant with it.
"In 1988, Sassenrath left Silicon Valley for the mountains of Ukiah valley, 2 hours north of San Francisco. From there he founded multimedia technology companies such as Pantaray, American Multimedia, and VideoStream. He also implemented the Logo programming language for the Amiga, managed the software OS development for CDTV, one of the first CD-ROM TV set-top boxes, and wrote the OS for Viscorp Ed, one of the first Internet TV set-top boxes."
Right? And I think that's what keeps bringing me back to REBOL, and thus Red. They don't appeal to me on the face of them. Like, the code examples look interesting but in a "magical" kind of way that strikes a little bit of fear into my engineering heart. But with that kind of pedigree, I can't dismiss the ideas. If Sassenrath came up with it, I bet there's a kernel of awesomeness inside.
I suspect a lot of the magic will fall away after realizing the block data structure (the square brackets) are pretty close to a Lisp list. And just like in Lisp, they're used for both code and data. One big difference is words are evaluated by default instead of just the first word in a list, so there's nowhere near as much nesting, and whenever an expression ends the next one can begin with no delimiter (but use newlines for legibility).
I used it once to build a simple web scraper and image downloader, and it worked really great for that. It was right in the wheelhouse for the language. (That was REBOL, not RED, and many years ago.) Honestly I'd just do it in Python, now, even though it's not as interesting.
This is what I used it for back in the day too. I was watching a demo of Robot framework for Selenium the other day and it reminded me of parsing pages with rebol. Not that they are similar, but perhaps because I thought rebol would be interesting to use with Selenium.
Same. I was regularly following it until they started talking about an ICO and began focusing too much on making a dialect for block chain stuff.
The idea between having the red system language, regular scripting language, cross platform gui, and native executables was really cool though. I remember being interested back in ~2015, so my question is...what's going on as it's been a decade. I know the project is crazy ambitious of course, but how close are we to where this is at a stage where most would consider it production worthy.
IIRC think their original roadmap had 1.0 around 2020. And that was going to include everything, including async written from scratch in a language where nothing was made for async.
Then the roadmap slipped, and then never mentioned again.
But I haven't looked at the language or discussions around it for a long while now.
For me, it even went off the rails before, when Nenad went to China because he was able to raise funds for the project. But he hadn't anticipated that he would be in charge and not the other way around. The situation seems to suit him perfectly. I don't think Red has any future at this point. In any case, the roadmap has always been stratospheric.
It gives you a way to proceed anyway, and is opt-in, and not run by any government. How is that “nanny state”? Also, given that it doesn’t torture and murder people, it’s not quite 1984 either.
I agree that this particular coding example looks good. I find it aesthetically pleasing for some reason. But like you I don’t know the language, which leaves me with a question, does this code make understanding the function’s operation and implicit usage contract (i.e. the function’s type) clear to a dev that does know the language?
I would assume it does, because I assume I be able to know these things in a comparable JS or Python example. But if that assumption is correct I really like the ‘look’ of Red.
I have tried Rebol out a little, multiple times over the years. it's a cool language. I like it.
I also got to know about Red early, followed it and tried it out for a bit.
but as others have said, that move to crypto, to fund the dev work and make the devs money, put me off for good. nothing wrong with making money, let them make plenty, I just didn't jive with crypto as a way of doing it.
This is like the only programming language I could never learn. I just don't understand anything and I can't build any mental model of what's going on behind the hood
I wrote a paper on REBOL back in college. It is very interesting, but the syntax is definitely weird. You might think of the function call syntax as being sort of Forth-like, but with the tokens in reverse order. So like a Lisp, but without required parentheses. e.g. in the example
send friend@rebol.com read http://www.cnn.com
`read` knows that it takes one argument, and `send` knows that it takes two, so this ends up being grouped like
(send friend@rebol.com (read http://www.cnn.com))
(which I think is valid syntax; that AST node is called a 'paren').
Weirdly, the language also has some infix operators, which seem a bit out-of-place to me. I have no idea how the 'parser'[1] works.
[1] 'parsing' happens so late that it feels funny to call it that. The thing that knows how to treat an array as a representation of an evaluatable expression and evaluate it.
> Weirdly, the language also has some infix operators, which seem a bit out-of-place to me. I have no idea how the 'parser'[1] works.
There are no keywords or statements, only expressions. Square backets ("blocks") are used for both code and data, similar to a Lisp list. The main language (called the "'do' dialect") is entirely polish notation with a single exception for infix operators: Whenever a token is consumed, check the following token for an infix operator. If it is one, also immediately consume the immediately following one to evaluate the infix operator.
This results in a few oddities / small pitfalls, but it's very consistent:
* "2 + 2 * 2" = 8 because there is no order of operations, infix operators are simply evaluated as they're seen
* "length? name < 10" errors (if "name" isn't a number) because the infix operator "<" is evaluated first to create the argument to "length?"
From your brief description that is likely incomplete, it looks as if the length? function is treated as a prefix operator of low precedence relative to the infix operators. The infix operators are all at the same precedence level and have left-to-right associativity.
I made an infix parser in which certain prefix operators (named math functions) have a low precedence. This allows for things like
1> log10 5 + 5 ;; i.e. log10 10
1.0
But a different prefix operator, like unary minus, binds tighter:
2> - 5 + 5
0
I invented a dynamic precedence extension to Shunting Yard which allows this parse:
Functions not registered with the parser are subject to a phony infix treatment if their arguments look like they might be infix and thus something similar happens to your Red example:
4> len "123" - 2
** -: invalid operands "123" 2
"123" - 2 turns into a single argument to len, which does not participate in the infix parsing at all. log10 does participate because it is formally registered as a prefix operator.
The following are also the result of the "phony infix" hack:
4> 1 cons 2
(1 . 2)
5> 1 cons 2 + 3
(1 . 5)
Non-function in first place, function in second place leads to a swap: plus the arguments are analyzed for infix.
Not sure why you got downvoted, but Rebol is not a Lisp. It doesn't work because of precedence rules or special rules, but because arguments accumulate until there are enough to eval the previous function in the stack, so you can do stuff like
print tostring 5 + cos pi
Works a bit like a shift/reduce parser, with heavy use of fexprs (blocks in Rebol parlance)
I think parsing there depends on the actual value of the current token. So if you assign send to another variable and use that the "parser" will still recognize that it takes 2 parameters.
It's an interesting design, definitely not something one sees frequently.
Even things that are normally keywords and statements in other languages (like conditionals and loops) are actually just functions that conform to the exact same parsing rules.
The square brackets aren't really analogous to Lisp's parentheses; REBOL / RED use parentheses for the same purpose, if you need them. The square brackets are more like square brackets in Factor or Joy; they are 'quotations' around a list of words (or other syntactic structures; basically they make a list that is not evaluated immediately).
When I look at a programming language site, especially for a "new" language, I want a quick way to navigate to a reasonably sized decent code sample, ideally documented, showing off significant language features, idiomatic syntax and usage patterns etc...
Sites which do this well (just from the top of my head):
https://odin-lang.org/
immediate code sample visible
"See the Full Demo"
"See More Examples"
https://ziglang.org/
immediate code sample
scroll down a bit, "More Code Samples"
Here on red-lang.org... I can barely find a consecutive meaningful chunk of code... ?
"Getting Started" Nope
"Documentation" Nope
"Official Documentation" link to github
https://github.com/red/docs/blob/master/en/SUMMARY.adoc
"Home"
merely a chronologically sorted blog
newest entry links to 50 line "script" by chance
showing off multi-monitor support
(doesn't seem like a super helpful sample)
?
But no one has bothered to write a complete manual like Carl did for Rebol, and the language is a partial implementation in Rebol which has a hybrid Rebol/Red syntax that must ultimately be bootstrapped in Red. In short, you have the scaffolding around it and if you are not a total fan or a dev of the project it is not even worth it.
They used to promise that proper docs and everything would come when the language reaches 1.0. That was 7 years ago. The language is at version 0.6.6 today, and the state of docs is the same as 7 (and 10) years ago.
There are at best two people working on the language, and they both don't have the time and have a very weird approach to docs (like posting extensive google docs or pastebin explanations, but never actually having any proper documentation)
ah, this is not about the Red Language that Intermetrics designed in 1977-79 to satisfy the Steelman requirements of the DoD's High Order Language Working Group... (the Green Language won and became known as Ada).
I thought maybe someone had put the DoD's Red language spec online.
Maybe it's just bias based on what I'm familiar with but I don't really like the syntax, or at least I can't understand any of it intuitively. Looking at the few examples I can find, it doesn't appear to be obvious without having to look at and interpret a bunch of surrounding context for clues to what a particular token is, e.g. a function name, a variable, an argument to a function and what function it is an argument to, the type of a variable, a value being assigned to it, etc. I see a lot of lines of code that are just several strings in a row without any sort of punctuation.
So, REBOL and Red are basically Fexpr-based Lisps, right? They never describe themselves this way (instead using terms like definitional scoping, etc.), but it all just seems like a non-rigorous Fexpr based Lisp (almost like a light-weight version of vau-calculus of Kernel).
I don't think in Red a function can decide whether to evaluate its arguments or not. It's more like a Logo: functions have fixed arity, so you don't need to delimite the call, and lists ("blocks") are always quoted, so you need to explicitly evaluate them.
red-lang.org is blocked!
Phantom believes this website is malicious and unsafe to use.
This site has been flagged as part of a community-maintained database of known phishing websites and scams. If you believe the site has been flagged in error, please file an issue.
Ignore this warning, take me to https://www.red-lang.org/p/about.html anyway.
There aren't many parser libraries for languages other than ruby. Its Ruby implementation, Asciidoctor, is considered as the reference implementation. However, it's being standardized and the situation will hopefully improve.
It's a little more complex, but I like it too. I've worked in teams that put all in-repo documentation in Asciidoc, it was really nice for adding in diagrams of complex systems and dependency trees.
> Red’s ambitious goal is to build the world’s first full-stack language, a language you can use from system programming tasks, up to high-level scripting through DSL.
Pretty nonsensical statement. We have that for 50 years. Common Lisp, for example.
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
Go compiles massive codebases in that time. V can recompile itself probably 2-3x in that time.
I don't take any new language seriously unless it's memory safe, free of UB, able to interoperate with what already exists including optional shared libraries (because static linking the world every time in everything is memory and disk wasteful), and assists formal proofs of correctness. Otherwise, what already exists seems preferable for serious use and hobbies can remain fun distractions.
If a language can’t use shared objects at all, it’s really not much use, is it? Almost all languages make use of at least the posix syscall interfaces provided by the OS, and some platforms don’t even allow you to roll your own syscalls, iirc.
In my eyes it’s more important that FFI be easy, automatic, and as efficient as possible. Go imposes a significant cost on FFI, for example, and many languages have typesystems that are very unfriendly to C ABI or basically require swig.
One thing I really appreciate about Lua is that I can write Lua interfaces for my classes and methods quite easily, and even use Lua as a garbage-collected allocator for native types. Automating the generation of Lua interfaces can easily be done natively with metaprogramming, without involving dependencies like swig. It’s so good that instead of feeling like you’re figuring it out on the Lua side, it’s as if Lua puts the host language first, Lua doesn’t even need to be the owner of the process. It is almost ideal other than the clumsy interface between the stack-like C side and tables, and the dynamic parameter lists.
For so many languages FFI is an afterthought at best.
Languages that encourage making DSLs are a two-edged sword. On the one hand, you get to make a language that is more clear and fine-tuned to your use-case. On the other, you have an ad-hoc language with no support that you have to maintain along with the documentation (considering that you can't expect anyone else to know the DSL ahead of time). As I've gotten older, I've determined that well-designed APIs in a well-known language are a better alternative to DSLs.
I’m right there with you. Modern languages have such a plethora of tooling available that DSLs and any API approaching a DSL have this massive gap unless they really embrace whatever patterns the host language’s tooling enables.
Not long ago, i had to work with a coworker’s mini language and function runner engine, which was basically a mini programming language. Except without a debugger or type checker or stack traces or any of the other million niceties we’d have had if we just used the host language to execute things ‘natively.’
That said, while the level of tooling for big languages goes up, the bar for creating yesteryear’s tooling is going down, with all the LSP tooling we have now, for example. Maybe someday we’ll get languages with tools where libraries have nice tooling without crazy dev effort, and then we’ll change our tune on DSLs.
I like the idea of DSL, but in real projects, I hate almost every DSL introduced by coworkers.
Because they are really really difficult to get right almost as difficult as building a new language. But when they work well they can be a real boost.
I've come to hate DSLs. With rare exception, almost every DSL has become a brittle subset of the parent language.
Sometimes you want a specific limited subset of the parent language, especially when you don't want to expose a huge possibility space to non technical users. Exposing only a limited subset can also be helpful to sandbox for security reasons.
Even DSLs of huge and successful projects are more often than not bad. As a rule if you think that you can create a better query language than SQL, please spare us. JQL, Elastic Query DSL, KQL... Don't.
It has been interesting to watch the Clojure community’s take on DSLs over time. Clojure is a Lisp, and Lisps are notorious for inventing DSLs, particularly after PG’s various papers promoted that as a superpower of sorts. Clojure has gone the other direction and, while it supports macros, it generally discourages their use unless you’ve tried everything else first. But it still encourages DSLs built from the native Clojure data structures. So, for instance Hiccup for HTML generation.
The discouragement of macros I think is a knee-jerk reaction. Build around data structures and functions first, and then use the thinnest macros around that can be quite maintainable.
An API is just as much a DSL.
Kind of, except that a non-DSL API doesn't create any new syntax. Which means that you get to keep all sorts of quality-of-life tools like syntax highlighting and correctness checking in the editor, autoformatting, possibly some amount of linting, etc.
A few years ago I revisited Racket after a long hiatus, and that was maybe the biggest thing I noticed. I really don't like syntax macros as much as I did back in the day. Once I decide to use `define-syntax` I've then got to decide whether I also want to wade into dealing with also implementing a syntax colorer or an indenter as part of my #lang. And if I do decide to do that, then I've got a bunch more work, and am also probably committing to working in DrRacket (otherwise I'd rather stay in emacs) because that's the only editor that supports those features, and it just turns into a whole quagmire.
And it's arguably even worse outside of Racket, where I might have to implement a whole language server and editor plugin to accomplish the same.
Versus, if I can do what I need to do with a reasonably tidy API, then I can get those quality of life things without all the extra maintenance burden.
None of this was a big deal 20 years ago. My expectations were different back then, because I hadn't been spoiled by things like the language server protocol and everyone (finally) agreeing that autoformatting is a Good Thing.
Conversely, Ruby is often seen as facilitating DSL's, but none of it changes syntax, because the syntax as-is is flexible enough that redefining methods is sufficient. But everything still abides by the same syntactical rules.
The more orthogonal or flexible the language is, the less there tends to be a distinction between redefining syntactical elements and defining functions or methods.
> Kind of, except that a non-DSL API doesn't create any new syntax.
Internal DSLs are always (by definition) valid code in the host language; external DSL, where parsing and interpretation or compilation to executable code for raw text code in the DSL are implemented in the host language, are all new syntax, but “languages that encourage making DSL” are usually ones that are favored for internal, not external, DSLs.
I think that "internal DSL" is what the grandparent poster meant by API, so I just went with that.
I think the internal/external terminology might be kind of outdated, anyway? I think this might be the first time I've encountered it in the wild in over 10 years.
> I think that "internal DSL" is what the grandparent poster meant by API, so I just went with that.
When people talk about REBOL/Red (or Ruby or Lisps) encouraging making DSLs, they are referring to internal DSLs. In Ruby, these are just APIs consisting of normal objects and methods, in Lisps they often involve macro calls, which may or may not correspond to what people mean by an API, and in REBOL/Red the design of the language is such that “normal” functions can do things that would take macros in Lisp.
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.
I used to feel that way. I’m still not a convert, but now I’ve seen a lot more complexity papered over by a nice DSL.
Standard math syntax is a DSL. I understand math a lot more quickly than I understand the same thing written in 20 lines of code.
I think the language we use to express ourselves influence the quality of the product. If your language encapsulates complexity, then you can build more complicated things.
I’m not arguing in favor of specific (“pointless”) DSLs, but there’s a nice paper about making a video editing language in Racket [1] that makes a DSL seem pretty convincing.
[1]: https://www2.ccs.neu.edu/racket/pubs/icfp17-acf.pdf
The protocol buffer / grpc definition language is another great example of where a DSL can shine. Especially if you compare it to efforts to accomplish basically the same task using pre-existing languages, such as OpenAPI (JSON) and WCF (XML).
Captain Pedant here, but OpenAPI also accepts yaml which suffers from a ton less { and "
gRPC and I are not friends and I've thankfully never needed to interact with WCF
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?
Lisps support OO like you wouldn’t believe: https://lispcookbook.github.io/cl-cookbook/clos.html
You could write DSLs for them, but you could just as easily do it within the existing syntax. Which is exactly how all the popular lisp implementations of OO, concurrency and type checking work in practice.
Many of them do use macros. But that's not about creating a special language; that's about moving expensive computations and checks that can be done statically to compile time where they belong.
Any markup language is a DSL. Including HTML.
Netlists.
Makefiles.
And so on.
You really don't see the value of DSLs?
Except in homoiconic languages, like Rebol/Red/Lisp, there is no (need for a) new syntax.
Regex
TBH, I feel like regexes would be much easier to understand in a more literate form with standard syntax. Something like:
Where, in a real program, `domain` would be defined in a "standard library of constructions" that you can just import and re-use in more complicated regexes.Something like this can be implemented in any language with operator overloading, no DSL required. Without operator overloading, the syntax would be a bit more awkward, but still nicer than the current regexp madness.
I don't quite understand where regex gets its reputation from. I think that once you remember the meaning of the operators, it's not too bad. (And the concise syntax is actually very helpful.)
I get that the meaning of the operators is not clear unless you're already familiar with regex, but neither is the meaning of !, ?, %, &, |, ^, ~, &&, ||, <<, >>, *, //, &, ++ (prefix), ++ (postfix), and so on. You learn these because you need them once, and then they're burned into your mind forever. Regex was similar for me.
I think regex gets some of its hate from people writing painfully complex matchers. 99% of my day to day regex use is simpler string searches on the command line or in my editor. I’m really happy I took the time to learn the syntax (spent about a week on it around 15 years ago) because now it doesn’t get in my way.
Regex syntax helps you understand what a regex does, not necessarily why it does it.
You can't decompose it into parts, you can't give those parts human-friendly names, you can't re-use parts in other regexes, you can't (easily) write functions that return or manipulate regexes (like that "list with separator" function shown above).
The limitation with regex is that's it's context free, whereas a regular grammar is simpler and more powerful IMO.
Also, regexps are just that: regular. You can mostly read them from left to right decoding each symbol at a time.
recommend you check out raku Grammars … https://docs.raku.org/language/grammars
Or in Red's case, Parse - https://www.red-lang.org/2013/11/041-introducing-parse.html
There’s really nothing about this that couldn’t be expressed just as clearly in a more general API though, even in C, IMO. Building it into the syntax is a little weird to me.
Fair point, though I learned regexes a long time ago, so that they weren't on my "problems that I can solve with new syntax" list, but instead on the "syntax that's already there" list.
Or in Rebol/Red it's Parse, a dialect (DSL) that comes with the language - https://www.rebol.com/docs/core23/rebolcore-15.html
No, an API uses existing rules, but a DSL uses its own ad hoc rules.
GP is right. Don't make DSLs, make APIs, which are:
* More composable
* More reusable
* More simple to reason about
* More natively supported
* More portable
* More readable
* More maintainable
An API creates its own ad hoc rules too. They just don't change the grammar.
In languages where the grammar is sufficiently flexible, the distinction all but disappears, but even in languages where the grammar is rigid and API's stand out like a sore thumb, the API itself still creates a new rule-set that you need to learn.
You can choose to not call that a new language all you want, but the cognitive load is still there.
An API (as people usually mean by it, anyway…) is really just a simple grammar for the creation and manipulation of objects in the system. Those objects still have types and properties just like any other object, but they tend to be implicit and unreliable. A good DSL is just a more abstract and implicitly verb-oriented API. For example, Lua DSLs can resemble something almost like a sort of typed or tagged DDL. Translating that into an “API” just adds more clumsy legwork to achieve the same outcome.
Agreed - I was tempted to make the same claim that it is still a grammar, but decided against it as I suspected it'd get in the way of making the point. You're 100% right you can write a grammar for an API as well, or can consider the API definition it self as creating a grammar.
I've seen it. Sometimes a DSL is more readable than trying to shoehorn control flow into method calls (".then().catch()..."). Or see C#'s LINQ.
> Or see C#'s LINQ.
This might be one of the rare times it's worth it. The C# team alread has the experience and tooling to maintain a language. Maintaining a DSL might be a reasonable choice for them.
It's rarely a good idea for app or library devs to make a similar decision.
Yes, this reminds me of meta-programming in languages like Python, it's useful if you want to create a framework like Django, but if you work on products, chances are good you should not use it.
There are plenty of places where it makes more sense to use DSLs (or where they’re flat-out required). SQL and regex both spring to mind. Pretty much any HTML templating language is simpler to use than concatenation a bunch of strings together. JSX is usually easier read than directly calling React functions directly. A line of a shell script can be much nicer (and more portable) than 20 lines of a more general purpose language.
Those are things that spring to mind that I think are unequivocally DSLs, but if you’re willing to consider markup languages as DSLs, the list could get a lot longer.
Most people think of DSLs as a language you can create within a language. All the things you named are either entire languages themselves like HTML, SQL, and the shell family, or formal extensions of existing languages like JSX. A DSL would be something you could create inside JS tagged literals or Ruby.
I don't think of DSLs as strictly being embedded in another programming language. The term I would use for that is "eDSL", short for Embedded Domain Specific Language. See: https://wiki.haskell.org/Embedded_domain_specific_language
Martin Fowler on DSLs, including internal and external DSLs:
https://martinfowler.com/books/dsl.html
https://martinfowler.com/dsl.html
Also see:
https://en.m.wikipedia.org/wiki/Domain-specific_language
including the References section.
No, an API is a contract. Just like an object or a class or a structure is not a DSL. None of these modify the syntax or keywords of the language used to implement them, and only objects and classes actually have the ability to override operators.
Just grouping things together in a particular order and giving the group a name does not make a DSL.
The API creates a language just the same modifying syntax, by introducing new words with new meaning.
The point is that however you want to group it, the effect is the same: You introduce a whole new vocabulary that you need to learn the rules of.
A DSL is expected to add or break language rules. An API is not.
An API can be so complex as to be thought of as a DSL but that makes it bad.
An API is an interface, metaprogramming is a technique for building such interfaces by treating code as data. They aren't interchangeable concepts.
Metaprogramming comes in handy when ordinary programming results in a lot of complex, hence unmaintainable, code or can't achieve something due to how the language is implemented. It can vastly simplify how you express application logic, e.g. when interfacing with foreign programming languages such as SQL or generating code from data.
Any sane metaprogramming regime allows you to do something like macro expansion, i.e. look at the code the metaprogramming is compiled into in the current context.
this is a very important lesson. I remember the frustration of dealing with the Gradle and whatever was the name of the DSL used by Fastlane. Gradle especially kept changing so documentation was never really useful and there was zero help from the tooling
> and there was zero help from the tooling
That's mostly my experience with ruby, too: you can type anything, don't worry about it!
I wanted to mention that Gradle since I think about version 7 supports mostly static typing via Kotlin but regrettably it's lipstick on a pig since almost inevitably one needs to interact with the Groovy side of the house and then all bets are off
I've run the same frustration road.
And at least the last time I used it in anger (which was, granted, perhaps double digit years ago), the docs started out with and loudly proclaimed "here's how you write your own tasks!" Wait, what? I want to have a build system do at least the 80% case with minimal/zero work; why am I jumping right in to my bespoke needs?
Not sure if this was just bad doc, or the tool actually didn't do the 80% very well then or what, but it's stuck with me.
I heard that in Lisp every program becomes a DSL?
I wouldn't say that. It's just its trivial to make DSLs in languages like the various lisps (common lisp, racket, chez scheme...etc).
That's usually what people complain about (besides the parenthesis) in that it's easy to not be very disciplined.
Lisp is homoiconic, so there isn't really a distinction between programs and data. For example, a snippet of code like a for-loop iterating through a list is also a list that can be inspected and modified. Or something along those lines (there's an XKCD comic that captures the spirit where the person says "it's all CARs" as in lisp you can build everything from CAR, CDR, and CONS I think). You'll have to dig into that on your own. The terms are historically relevant, but seem antiquated now. I've never really understood macros (compile or runtime ones) all that well though, so hopefully someone else in the comics can clarify my mumbo jumbo.
https://www.explainxkcd.com/wiki/index.php/224:_Lisp
I've been thinking about this a lot. DSLs solve an important problem, but they do it in the wrong direction.
It's impossible to write objective fact. Everything we write is subjected to the context it is expressed in, including the grammar that we use to write it. A DSL accommodates this by letting you make a new grammar on the fly. The trouble is, this doesn't help us get out of the context we are writing in already: it only lets us enter a new one that is nested inside.
So what if we could actually get out? What if we could write from outside of the context we are writing? That's the idea I'm working on. I think it's possible, but it's such an abstract idea that it's tricky to get a handle on.
This is a successor to REBOL[0], designed by Carl Sassenrath[1] who designed the Amiga kernel.
I've looked it a few times over the years. It's neat. I've never written a single line of it, though.
[0]https://en.wikipedia.org/wiki/Rebol
[1]https://en.wikipedia.org/wiki/Carl_Sassenrath
I don't remember how I found it, but REBOL was one of the first programming languages I learned around 25 years ago. Most of my personal projects are still written in it.
I have yet to try converting anything to Red.
I remember first hearing about it on TechTv's The Screen Savers way back when I think. I'm pretty sure it was demoed on a segment at one point.
I wrote a small app in REBOL once, just too automate some stuff for some managers in a job about 20 years ago. It's quite nice, but I don't think I'd want to write anything significant with it.
"In 1988, Sassenrath left Silicon Valley for the mountains of Ukiah valley, 2 hours north of San Francisco. From there he founded multimedia technology companies such as Pantaray, American Multimedia, and VideoStream. He also implemented the Logo programming language for the Amiga, managed the software OS development for CDTV, one of the first CD-ROM TV set-top boxes, and wrote the OS for Viscorp Ed, one of the first Internet TV set-top boxes."
What a legend!
Right? And I think that's what keeps bringing me back to REBOL, and thus Red. They don't appeal to me on the face of them. Like, the code examples look interesting but in a "magical" kind of way that strikes a little bit of fear into my engineering heart. But with that kind of pedigree, I can't dismiss the ideas. If Sassenrath came up with it, I bet there's a kernel of awesomeness inside.
I suspect a lot of the magic will fall away after realizing the block data structure (the square brackets) are pretty close to a Lisp list. And just like in Lisp, they're used for both code and data. One big difference is words are evaluated by default instead of just the first word in a list, so there's nowhere near as much nesting, and whenever an expression ends the next one can begin with no delimiter (but use newlines for legibility).
pretty sure he finished out his post Rebol career with Roku
One can go to his web page to find out what he's doing with himself.
I used it once to build a simple web scraper and image downloader, and it worked really great for that. It was right in the wheelhouse for the language. (That was REBOL, not RED, and many years ago.) Honestly I'd just do it in Python, now, even though it's not as interesting.
This is what I used it for back in the day too. I was watching a demo of Robot framework for Selenium the other day and it reminded me of parsing pages with rebol. Not that they are similar, but perhaps because I thought rebol would be interesting to use with Selenium.
I figured they were cooked when they started doing weird cryptocurrency-related stuff. I really hope they get to their 1.0 release someday.
Same. I was regularly following it until they started talking about an ICO and began focusing too much on making a dialect for block chain stuff.
The idea between having the red system language, regular scripting language, cross platform gui, and native executables was really cool though. I remember being interested back in ~2015, so my question is...what's going on as it's been a decade. I know the project is crazy ambitious of course, but how close are we to where this is at a stage where most would consider it production worthy.
IIRC think their original roadmap had 1.0 around 2020. And that was going to include everything, including async written from scratch in a language where nothing was made for async.
Then the roadmap slipped, and then never mentioned again.
But I haven't looked at the language or discussions around it for a long while now.
Edit: found some old discussion here. In 2018 they were at version 0.6.4 https://news.ycombinator.com/item?id=18864840
In 2025 they are at version 0.6.6: https://github.com/red/red/releases
For me, it even went off the rails before, when Nenad went to China because he was able to raise funds for the project. But he hadn't anticipated that he would be in charge and not the other way around. The situation seems to suit him perfectly. I don't think Red has any future at this point. In any case, the roadmap has always been stratospheric.
can you elaborate what you mean by not anticipating that he would be in charge?
btw, i met him in beijing while he was there.
That he would not have been able to do what he hoped to do to meet other demands of his creditors. Pure speculation.
Interesting, that at least explains why this happens a little bit.
https://i.imgur.com/a/phd4lVr
Holy nanny state. The authors of a language have thought about using cryptocurrency, so it's flagged as a phishing and scam site? Literally 1984.
It gives you a way to proceed anyway, and is opt-in, and not run by any government. How is that “nanny state”? Also, given that it doesn’t torture and murder people, it’s not quite 1984 either.
It's a community maintained block list. You may be able to do something about it. So, not 1984 all the way.
That message was created by... the state?
Here [0] is an example of what it looks like. Took some digging to find, really should be more prominent on the site.
It's very elegant! I can't fully grasp everything that's happening but the visual appearance of the syntax alone is interesting.
[0] https://github.com/red/code/blob/master/Scripts/clock.red
I agree that this particular coding example looks good. I find it aesthetically pleasing for some reason. But like you I don’t know the language, which leaves me with a question, does this code make understanding the function’s operation and implicit usage contract (i.e. the function’s type) clear to a dev that does know the language?
I would assume it does, because I assume I be able to know these things in a comparable JS or Python example. But if that assumption is correct I really like the ‘look’ of Red.
Seems someone built an ETL product from XML to databases.
https://redata.dev/smartxml/
If it's robust it seems rather neat.
I have tried Rebol out a little, multiple times over the years. it's a cool language. I like it.
I also got to know about Red early, followed it and tried it out for a bit.
but as others have said, that move to crypto, to fund the dev work and make the devs money, put me off for good. nothing wrong with making money, let them make plenty, I just didn't jive with crypto as a way of doing it.
sad about it going that route
This is like the only programming language I could never learn. I just don't understand anything and I can't build any mental model of what's going on behind the hood
I wrote a paper on REBOL back in college. It is very interesting, but the syntax is definitely weird. You might think of the function call syntax as being sort of Forth-like, but with the tokens in reverse order. So like a Lisp, but without required parentheses. e.g. in the example
`read` knows that it takes one argument, and `send` knows that it takes two, so this ends up being grouped like (which I think is valid syntax; that AST node is called a 'paren').Weirdly, the language also has some infix operators, which seem a bit out-of-place to me. I have no idea how the 'parser'[1] works.
[1] 'parsing' happens so late that it feels funny to call it that. The thing that knows how to treat an array as a representation of an evaluatable expression and evaluate it.
> Weirdly, the language also has some infix operators, which seem a bit out-of-place to me. I have no idea how the 'parser'[1] works.
There are no keywords or statements, only expressions. Square backets ("blocks") are used for both code and data, similar to a Lisp list. The main language (called the "'do' dialect") is entirely polish notation with a single exception for infix operators: Whenever a token is consumed, check the following token for an infix operator. If it is one, also immediately consume the immediately following one to evaluate the infix operator.
This results in a few oddities / small pitfalls, but it's very consistent:
* "2 + 2 * 2" = 8 because there is no order of operations, infix operators are simply evaluated as they're seen
* "length? name < 10" errors (if "name" isn't a number) because the infix operator "<" is evaluated first to create the argument to "length?"
From your brief description that is likely incomplete, it looks as if the length? function is treated as a prefix operator of low precedence relative to the infix operators. The infix operators are all at the same precedence level and have left-to-right associativity.
I made an infix parser in which certain prefix operators (named math functions) have a low precedence. This allows for things like
But a different prefix operator, like unary minus, binds tighter: I invented a dynamic precedence extension to Shunting Yard which allows this parse: Functions not registered with the parser are subject to a phony infix treatment if their arguments look like they might be infix and thus something similar happens to your Red example: "123" - 2 turns into a single argument to len, which does not participate in the infix parsing at all. log10 does participate because it is formally registered as a prefix operator.The following are also the result of the "phony infix" hack:
Non-function in first place, function in second place leads to a swap: plus the arguments are analyzed for infix.Not sure why you got downvoted, but Rebol is not a Lisp. It doesn't work because of precedence rules or special rules, but because arguments accumulate until there are enough to eval the previous function in the stack, so you can do stuff like
Works a bit like a shift/reduce parser, with heavy use of fexprs (blocks in Rebol parlance)I know you enjoy Lisps, so you might like this toy Rebol evaluator written in Scheme: http://ll1.ai.mit.edu/marshall.html
I'm guessing because their understanding is still wrong:
In Rebol this would be equivalent to (log10 (5 + (5 + (log10 (5 + 5)))))> I have no idea how the 'parser'[1] works
I think parsing there depends on the actual value of the current token. So if you assign send to another variable and use that the "parser" will still recognize that it takes 2 parameters.
It's an interesting design, definitely not something one sees frequently.
but why, don't get this design choice at all.
It takes the common "function(arg1, arg2)" pattern and turns (almost) the whole language into a very simple/consistent https://en.wikipedia.org/wiki/Polish_notation
Even things that are normally keywords and statements in other languages (like conditionals and loops) are actually just functions that conform to the exact same parsing rules.
it's lisp with square braces instead of parens (and then a whole bunch of other random things like a gui library in the standard library?)
The square brackets aren't really analogous to Lisp's parentheses; REBOL / RED use parentheses for the same purpose, if you need them. The square brackets are more like square brackets in Factor or Joy; they are 'quotations' around a list of words (or other syntactic structures; basically they make a list that is not evaluated immediately).
It's actually more like Logo, which is Lisp with square brackets instead of parens and fixed arity.
Sassenrath wrote Amiga Logo before starting REBOL.
>This is like the only programming language I could never learn.
Wait till you hear of Urbit and see this: https://developers.urbit.org/overview/nock
It's worth noting this work came from a prominent internet extremist. A generous interpretation would be that it is a high-effort troll.
It makes more sense (or helps you buy into the marketing, if you prefer) if you read the short story that Tlon took its name from.
I spent too long trying to learn this & hoon, not worth it ;_;
When I look at a programming language site, especially for a "new" language, I want a quick way to navigate to a reasonably sized decent code sample, ideally documented, showing off significant language features, idiomatic syntax and usage patterns etc...
Sites which do this well (just from the top of my head):
Here on red-lang.org... I can barely find a consecutive meaningful chunk of code... ?You can watch https://www.red-by-example.org/
But no one has bothered to write a complete manual like Carl did for Rebol, and the language is a partial implementation in Rebol which has a hybrid Rebol/Red syntax that must ultimately be bootstrapped in Red. In short, you have the scaffolding around it and if you are not a total fan or a dev of the project it is not even worth it.
They used to promise that proper docs and everything would come when the language reaches 1.0. That was 7 years ago. The language is at version 0.6.6 today, and the state of docs is the same as 7 (and 10) years ago.
There are at best two people working on the language, and they both don't have the time and have a very weird approach to docs (like posting extensive google docs or pastebin explanations, but never actually having any proper documentation)
ah, this is not about the Red Language that Intermetrics designed in 1977-79 to satisfy the Steelman requirements of the DoD's High Order Language Working Group... (the Green Language won and became known as Ada).
I thought maybe someone had put the DoD's Red language spec online.
And yes, someone has: https://iment.com/maida/computer/redref/
Maybe it's just bias based on what I'm familiar with but I don't really like the syntax, or at least I can't understand any of it intuitively. Looking at the few examples I can find, it doesn't appear to be obvious without having to look at and interpret a bunch of surrounding context for clues to what a particular token is, e.g. a function name, a variable, an argument to a function and what function it is an argument to, the type of a variable, a value being assigned to it, etc. I see a lot of lines of code that are just several strings in a row without any sort of punctuation.
So, REBOL and Red are basically Fexpr-based Lisps, right? They never describe themselves this way (instead using terms like definitional scoping, etc.), but it all just seems like a non-rigorous Fexpr based Lisp (almost like a light-weight version of vau-calculus of Kernel).
I don't think in Red a function can decide whether to evaluate its arguments or not. It's more like a Logo: functions have fixed arity, so you don't need to delimite the call, and lists ("blocks") are always quoted, so you need to explicitly evaluate them.
Not very reliable, this Phantom thing.
I know asciidoc from red and erlang, it's a nice language. Not sure why it is not as popular as markdown.
There aren't many parser libraries for languages other than ruby. Its Ruby implementation, Asciidoctor, is considered as the reference implementation. However, it's being standardized and the situation will hopefully improve.
It's a little more complex, but I like it too. I've worked in teams that put all in-repo documentation in Asciidoc, it was really nice for adding in diagrams of complex systems and dependency trees.
32 bit only
Which is a deal breaker for macOS users... unless they are still on Mojave.
In Red, you'll presumably always know what color your functions are.
> Red’s ambitious goal is to build the world’s first full-stack language, a language you can use from system programming tasks, up to high-level scripting through DSL.
Pretty nonsensical statement. We have that for 50 years. Common Lisp, for example.
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)
The repo seems to be alive and kicking.
I haven’t looked at this in detail, but it seems they confuse “human-friendly syntax” with “absence of (<[{“.
I cant find some stuff from the docs. What i am wondering is:
For 'platforms' it notes for x86_64, "linux" and other operating systems.
is there a compiler option for this thing to make it spit out a 'freestanding' binary for the architectures it supports?
(2011,2013)
Seems the last release (alpha) was in 2015.
red was terrible in 2018, and its terrible now - just tried to compile hello world and it takes 36 seconds
https://github.com/red/red/issues/5615
Go compiles massive codebases in that time. V can recompile itself probably 2-3x in that time.
I don't take any new language seriously unless it's memory safe, free of UB, able to interoperate with what already exists including optional shared libraries (because static linking the world every time in everything is memory and disk wasteful), and assists formal proofs of correctness. Otherwise, what already exists seems preferable for serious use and hobbies can remain fun distractions.
If a language can’t use shared objects at all, it’s really not much use, is it? Almost all languages make use of at least the posix syscall interfaces provided by the OS, and some platforms don’t even allow you to roll your own syscalls, iirc.
In my eyes it’s more important that FFI be easy, automatic, and as efficient as possible. Go imposes a significant cost on FFI, for example, and many languages have typesystems that are very unfriendly to C ABI or basically require swig.
One thing I really appreciate about Lua is that I can write Lua interfaces for my classes and methods quite easily, and even use Lua as a garbage-collected allocator for native types. Automating the generation of Lua interfaces can easily be done natively with metaprogramming, without involving dependencies like swig. It’s so good that instead of feeling like you’re figuring it out on the Lua side, it’s as if Lua puts the host language first, Lua doesn’t even need to be the owner of the process. It is almost ideal other than the clumsy interface between the stack-like C side and tables, and the dynamic parameter lists.
For so many languages FFI is an afterthought at best.
troll spotted