I think my favorite thing is the `…` operator. Go check it out. It’s not like the splat operator in other languages, though it does give that feel initially. It’s much more general: it works with nested data structures and can take the place of a `map` operation.
The best part of `…` is that it is not a built-in thing—it’s just a macro! The magic is that Rhombus lets you define different macros depending on whether or not the macro identifier appears in binding context (left side of `=`), expression context, or some other contexts. IIRC you can even define your own contexts too.
Rhombus takes the best-in-class macro system of Racket and somehow finds a way to improve upon it. I say this after researching and comparing detailed metaprogramming features across a dozen different languages. Rhombus is a very neat little language.
Last thing: Rhombus’ main data type, the list, is implemented with an RRB tree. RRB trees support structural sharing, functional updates, and have O(log n) iterate, insert, delete, append, and arbitrary read operations. The constant factor on that is tiny: I think it’s like log_16 or log_32. They’re designed to be very cache friendly. Super cool data structure.
Finally someone uses the rrb tree as their main data structure! I implemented it for c# and the performance tradeoff compared to List<> was smaller than i had thought.
Thanks! I havet always been linking to the Collections subdir so I have missed this dumb issue. Will fix next time I use a computer. Might be some time though.
If you have any questions about the trees, feel free to ask.
That's both extremely neat and, for the time being, extremely hard for me to get my head around. I got it round monads, so I imagine it's just a matter of time!
> I think my favorite thing is the `…` operator. Go check it out. It’s not like the splat operator in other languages, though it does give that feel initially. It’s much more general: it works with nested data structures and can take the place of a `map` operation.
Something akin to `destructuring-bind' in Common Lisp?
I was not very involved in this. I still prefer s-expressions.
Anyway, my main initial concern was how to make good macros without s-expressions. There is a nice video by Matthew Flatt in RacketCon 2023. The first 6 minutes and 20 seconds are internal stuff, so skip to the 380s that I added in this link: https://www.youtube.com/watch?v=OLgEL4esYU0&t=380s He takes like another 6 minutes to explain the general idea and make some wishes, and then at the 12m mark he defines macros in Rhombus and makes the wish real in just 2m (with some enhancements later).
I mean, M-expression was proposed right from the start.
Then there is nothing special about having the brackets around. To start with, text can be just as readable:
( + 1 2 )
do plus 1 2 go
And one can use stack base syntax, or define a static default arity to infix notation, example two, so `times plus 1 2 3` is not ambiguous and is really clearly like (1+2)*3 with such a convention. Then you can shift arity with reserved word so `unary plus 1` is like `+1` or `arity 5 action one two three four`, or going back to explicit marker like `(` and `)` or `do` and `go` to group stuffs without explicitly quantified numbering.
"Modern programming languages reflect a consensus on the most important programming concepts, including lexically scoped variables, closures, objects, pattern matching, and type parametricity. Why, then, yet another programming language?"
I love this as a start. More programming languages need to start the conversation this way.
However, it whiffs after this when it fails to answer the question. Or at least fails to answer it in a way I understand. The next paragraph should not start with "Beyond the basics, there are still more good ideas for programming constructs than can fit in any one language specification." - cut straight to what the "programming constructs" are.
This section ends with "approachable" and "extensible". These are nothing. When considering the reasons for a language, look at the negation. Nobody writes a language to be "unapproachable"... well, unless you're on the esolang wiki, but that's not really what we're talking about here. Nobody really wants to stick "non-extensible" on their language either... where we all disagree is in the how one extends things. As someone reading this screen to decide if I'm interested these attributes mean nothing to me.
The page does get around to making it clear that there is a huge focus on macros, which is something, but it takes a while to get there.
That's a legitimate selling point. It's especially a selling point if you can explain clearly how this is different from just using Scheme directly. I have no idea if your language does this but I've long thought that it would be interesting to have a macro-focused language that went all-in on making them debuggable. Have the language compiler and runtime support dynamically exploring them, expanding them in your editor, re-contracting them, full debugging support, just go all-in on supporting that work flow. That would be an example of that sort of thing.
> When considering the reasons for a language, look at the negation. Nobody writes a language to be "unapproachable"… Nobody really wants to stick "non-extensible" on their language…
And yet, unapproachable languages and non-extensible languages exist. More specifically, there are languages where approachability and extensibility formed no part of the design goals and it shows.
I'm coming from Go, so apologies in advance if these questions seem a little weird:
How do I distribute my Rhombus programs? Can I cross compile to other architectures/OSs, ideally with a static binary?
What about libraries? Is there a good package manager? I presume from the post that the library ecosystem is pretty immature (maybe the Racket ecosystem is larger). Can I easily build a CRUD web app?
Is concurrency easy to make correct? Are tests easy to write? Tests involving concurrency? Race detection?
Dev experience: is it statically typed? I couldn't really tell from a quick search. Will the build system make a fast feedback loop for me and LLMs? Is it IDE friendly (auto complete, find all references, etc)? Is there language server support so I can bring my own editor? Will the macros mean I have to learn a bunch of DSLs to use anyone's library? Do the DSLs have IDE support?
Wow that's a lot of questions ;) It looks like a fun language in any case. And the fact that its even possible to make a Pythonic language on top of a LISP is its own showcase for Racket's power
> How do I distribute my Rhombus programs? Can I cross compile to other architectures/OSs, ideally with a static binary?
You can compile them inside DrRacket and distribute the .exe or equivalent. I used that a few times to send programs written in Racket to coworkers that are not programmers (remember to add an icon so it looks professional).
> What about libraries? Is there a good package manager? I presume from the post that the library ecosystem is pretty immature (maybe the Racket ecosystem is larger).
Some libraries have been ported to make them more idiomatic, in particular changing the name of the functions and fixing the different meaning of "list". Anyway, you can import any library of Racket from Rhombus and vice versa https://docs.racket-lang.org/rhombus-guide/Modules.html
> Can I easily build a CRUD web app?
Sorry, I never tried.
> Dev experience: is it statically typed? I couldn't really tell from a quick search.
It's optional. You can add statically types when you want and the code will be more efficient and get compile time errors. Or avoid them and get run time error.
> Will the build system make a fast feedback loop for me and LLMs?
Sorry, I never tried.
> Is it IDE friendly (auto complete, find all references, etc)? Is there language server support so I can bring my own editor?
auto complete: no (I think)
find all references: yes
> Will the macros mean I have to learn a bunch of DSLs to use anyone's library? Do the DSLs have IDE support?
Most macros try to blend with the language and be invisible, but it's possible to write weird and bad macros too. Most libraries should not define weird macros.
Anyway, some internal parts of Racket like `for` or `match` are implemented in Racket and are like two complete DSLs on their own.
Matthew Flatt picked “shrubbery” because it’s tree-like but not fully expanded, so it tends to be more broad/flat than deep like a tree. Hence also the term “enforrestation” when you fully expanded it.
I think the Monty Python reference is just a happy coincidence.
We do a "Lyrical Code" T-shirt where people submit song lyrics as code in their favorite language and then we pull verses from different languages to make a polyglot t-shirt. Last year at the conference, attendees voted for Never Gonna Give You Up as this year's song.
We're a little low on PR's this year unfortunately though. I don't know if it's all the AI or something else but we usually have about a dozen entries by now and we've only got 2 for some reason this year.
A lot of people hate sexprs. Even seemingly reasonable folks.
I imagined they have met students that really struggle with the syntax, while grokking the concepts easily.
I myself have heard "the parentheses are hard to balance" and "after a while you dont even see the parentheses" enough times that I think maybe both can be correct.
You got that exactly backwards. A non-lisper unavoidably has to deal with tons of syntactic and semantic clues - parens, colons & semicolons, square brackets, indentation & white-space, special chars, static type annotations, lsp servers and tree-sitter parsers. Lisp only needs two things - a [small] set of structural idioms, and a live REPL.
In all my time I have never come across a single Lisper, neither in person nor online, and I know far more than a few dozens, who once grokked the REPL-driven workflow and the structural editing idioms only to later, for whatever reason, suddenly start disliking or even hating s-expressions.
All that so-called "hatred" stems from unfamiliarity. People fuss about Lisps lacking static types, without a single clue about how a "true" REPL trades them off for something different. They compare it to a Python or C# REPL and think "it ain't a big deal". Well, the Lisp REPL is quite different, and yes, a major deal - every single part of the Read-Eval-Print-Loop differs. They complain about "hard to deal with parentheses" and "I can't refactor without types" while having no clue how amazingly nice structural editing is in practice, that you never even think about parens - you only see structure, order and reason.
well, i guess i know what the grandparent was talking about when they said 'I myself have heard [...] "after a while you dont even see the parentheses" enough times [...]'. Thanks for the example.
As I said, i think they have been teaching long enough to have a pretty good basis for the claim that racket's syntax can be a problem.
I am firmly in the "after a while you don't see the parentheses" camp, but I have a friend who I respect a lot who works in clojure (with Emacs/cider/paredit) that just doesn't like it.
I mean, I prefer sexprs above all other syntaxes, and I have had people tell me I just need to get used to indentation syntax or whatever they fancy.
> In all my time I have never come across a single Lisper, neither in person nor online, and I know far more than a few dozens, who once grokked the REPL-driven workflow and the structural editing idioms only to later, for whatever reason, suddenly start disliking or even hating s-expressions.
And we've never seen bullet holes in these parts of the plane, so there's no point putting armour there.
It's not about survivorship bias, it's about notation. It's like "hating Leibniz's dy/dx because Newton's dot notation already exists" and I'm arguing that people don't just "hate the notation", they simply misunderstand the principles of calculus. I'm not saying that notation preferences don't have consequences, but in this case, I've seen far too often the evidence that programmers ignore the underlying ideas outright, simply because they didn't like the notation on first sight.
This is survivorship bias. People who don't like s-expr aren't lispers.
I've used Lisp before. I can read s-expr code. Unfamiliarity is not the issue. I just don't like them. I don't like Haskell/ML either, and I've written large projects in both, so it's not a Lisp-specific thing.
That is what I don't get. I have used many different languages, and often is not the syntax that I don't like - I may dislike the semantics, the runtime, the tooling, but syntax, really how? It's like "I hate Greek alphabet", even though this is a weird comparison - alphabet is a flat bag of arbitrary symbols with no structural role, so disliking it sounds incoherent by construction. I just can't ever get over "s-expressions hate", in such a way like: "What are you even talking about? There's practically zero syntax in Lisp."
I have quite the opposite effect. I don't "hate" programming languages, but honestly, sometimes I don't understand how the fuck we (people) managed to build layers and layers of complexity (both syntactic and semantic) for things that can be concisely and simply explained as simple Lisp forms.
I get bonkers hysterical laughs sometimes, grabbing a piece of Java, Typescript or Python and asking an LLM how a similar code would look in Clojure. That doesn't universally yield "better" results; sometimes, the code may look certifiably more cryptic than the original - brute-forcing an algorithm into Lisp can look very terse, but that's up to the coder - I am capable of writing cryptic yet functioning code in any language.
I love Lisps, ML-family languages, etc. Languages like Java or Go are just painful for me to program in, and I know I’m probably in the minority there.
But honestly, I think a lot of it comes down to the fact that syntax carries semantic expectations. Certain syntax makes you expect a certain model of programming: mutability, imperative control flow, objects everywhere, etc.
Gleam is a good counterexample. It has an ALGOL-ish syntax, but semantically it’s a functional language, and it’s wonderful to read/write.
Same with Ruby: the parts of Ruby that still make me smile are mostly the parts that feel Lisp-adjacent.
It’s kind of wild that we live in a world where, for most programmers, syntax seems to matter more than semantics.
True! Syntax is a signaling system. Braces and semicolons signal the C-family, so you prepare for statements, mutation, sequential side effects, and objects. Parentheses-first signals Lisp, so you expect recursion and macros. Significant whitespace signals Python. Before you have read a single semantic line, the notation has already established a prior expectation. That is real, and most language discourse ignores it.
But syntax carries more than semantic expectations. It signals era, tribe, tooling, and aesthetics too. The paren signal says Clojure, CL, Emacs, REPL, niche, old-and-proud as loudly as it says functional. Some of the aversion to parentheses originates from sociological resistance to these signals rather than from semantic concerns. Yet honestly, grokking Lisp can make a true polyglot out of a coder. It did it for me. "A Lisper" is not always someone who writes and reads Lisp full-time. Fully fluent Lisper can rationally and successfully use any other PL syntax, because they understand the semantics, even though they'd actively try optimizing the connotation and ergonomics layer, a genuine separate axis.
I think if you believe that the aids types give for refactoring are equivalent to structural editing, then you are the one who might not get the value of typing information (I say this as a Python person, and am totally willing to accept lack of typing info in plenty of situations)
REPLs are nice and good, but when you're working on large enough systems it's nice to have some static foundations for your facts.
I don't "believe" things, I pragmatically choose the tools that work, the ideas that have merits. I did not say "refactoring is equivalent to structural editing", and I specifically talked about comparing Python REPL to Lisp's.
I don't lack experience working with type systems, I have used over a dozen different PLs, some of them were weirdly unusual - I once even had to program in a language with all operators in Russian.
> when you're working on large enough system
I have built and supported sufficiently large systems in various languages, and have seen firsthand the trade-offs Lisp systems can bring. The holistic experience of using Clojure often can beat systems with advanced static types, but you probably won't ever notice it, because you'd first demand something to "believe" in.
You guys (replying to the comment) seem to be convinced of my one-sided bias for defending s-expression syntax and dying for it. I'm defending it only because it gets bad rap from people unfamiliar with the merits. REPL-driven workflow, live image, structural editing, homoiconicity, code-as-data - none of these require the surface syntax to be parens and Rhombus is the living proof. Structural editing operates on any AST. The actual jewel is homoiconicity, and sadly it gets largely ignored by the majority of programmers today. S-expressions probably are the simplest form of syntax to operate homoiconic entities - the simplest notation that is at once a fully explicit tree and directly the language's own data structure. "I love homoiconicity" does not uniquely entail "I love parentheses", alas, programmers off the bat hate parentheses, often without even attempting to understand their significance - they think it's "aesthetic choice". They don't even for a second look around and get curious for why people keep making new Lisp dialects, 70 years on.
- For a programmer who never learned Lisp as their first language. I have met people who learned Clojure as their very first PL and they said it was fun. Later there were utterly confused about Java, Python and Javascript. Going the opposite may feel confusing and identity-breaking.
- Reading static code. In a sense, it can be a bit harder to read a wall of Lisp, say printed on paper. Lispers typically don't inspect "dead code" like that; they'd connect to the live REPL and eval expressions on the go, programming it from "inside out". With experience, it becomes easier to scan the code and mentally parse it. Lisp at that point actually gets far more readable than any other PL. For instance, Lisp code is better suited for smaller screens of smartphones - the code wraps around yet retains its readability. Try that trick with literally any other language, I can 100% guarantee - most of them would look like a huge pile of indecipherable mess.
> For a programmer who never learned Lisp as their first language
Maybe. But I have never heard anyone say that Python is hard to read, and it's one of the most common complaints against Lisps. Just looking at them both it's hard to imagine how one could seriously believe that s-expressions are more readable. `(== a b)` is clearly worse than `a == b`. Even JavaScript programmers know that.
> they'd connect to the live REPL
Yeah I dunno this is the same cop-out Ruby programmers use to justify its lack of static typing. It's fundamentally better if you can understand code without having to run it.
It's clearly worse just because it moved from infix to prefix and is wrapped by parens? Is `(* (+ a b) (+ c d))` clearly worse than `(a + b) * (c + d);`? Both have a bunch of parens, and one even has a semi colon.
This works both ways. `(list 1 2 3)` is clearly better than:
var l = new List();
l.add(1);
l.add(2);
l.add(3);
It's also better than `var l = [1, 2, 3];`
How often are you trying to make sense of a bunch of infix arithmetic operations when you're programming? Separately, how often are you creating data structures, navigating data structures, handling data in the form of JSON or XML, parsing that data into your language's native data structures, etc.?
Reading arithmetic in prefix instead of infix is easy, even if it is counter to how you were taught in elementary school. Working with s-expressions for code and data is clearly better than whatever syntax your language uses for code and either directly instantiating data or reaching for JSON or XML.
> justify its lack of static typing
Racket has both Typed/Racket as well as contracts.
Don’t you know that :’( is actually a trigraph for meta-quote-expression·opening ? Such a a reckless move as a lone mere literal closing bracket could destabilize the cosmic equilibrium entirely!
Being in the Lisp family, an often heard criticism is its use of parenthesis (disclaimer: I understand the difference between syntax & semantics. But syntax does matter).
It‘s a source of problems with mismatched tabs/spaces being used for indentation between team members for fairly little upside.
Imo it also makes moving blocks of code more cumbersome.
Shrubbery, Rhombus's first-pass indentation-sensitive syntax, has a syntax form to facilitate copy-paste.
With guillemets, « and », you can make a section of Shrubbery code indentation-insensitive. The idea for copy-paste it to "armor" the section you want to copy with guillemets in the right places, and unarmoring it after posting.
This needs editor support to do fluidly, but imo it's much better than trying to copy-paste the indentation-sensitive syntax.
I can't tell from my 5 minutes of poking DrRacket whether it supports this "armoring", I've been writing Shrubbery in nvim, which, unsurprisingly, does not support it.
Any language with significant indentation ends up specifying "Indent with spaces, not tab characters" for just that reason. As I recall, Python had that as a recommendation while F# ended up with it as a requirement, but it's been a while since I looked at that so I could be wrong. But in my experience, the category "people who complain about significant whitespace" is nearly a subset of the category "people who prefer tabs over spaces for indentation".
(Moving blocks of code around is not a real problem if your editor is capable of easily highlighting the thing that was just pasted. Because then you just hit that key binding, then press `>` or `<` — or Tab/Shift+Tab if you are using an inferior editor ;-) — until the indentation is where you need it. I haven't found it to be a big problem in practice when writing Python, though mileage will likely vary).
For me, the alternative solution makes much more sense for a language with significant indentation, i.e. to use only tabs for indentation and to completely prohibit spaces before the first printable character of a line.
I do not know why I have never seen this solution in practice.
It depends on the language's indentation requirements. That can work in Python, where you never need to line things up with characters above that aren't a multiple of an indent level. But in F#, at least a few years ago when I tried it, there are times when you would need (or strongly want) to line things up with other characters. For example, this example from https://learn.microsoft.com/en-us/dotnet/fsharp/style-guide/...:
functionName
arg1
arg2
arg3
(function
| Choice1of2 x -> 1
| Choice2of2 y -> 2)
Note how the | needs one extra space in order to line up with the word "function", due to the open parenthesis. If you're using tabs for indentation, that means you need a series of tabs plus one trailing space after the tabs, in order to line up the | correctly.
Any situation where you must have a mixture of tabs and spaces for code to work right leads to a nightmare. Because it makes you have to turn on visible whitespace in your editor and peer closely at the lines. I have a simple rule: "Do NOT make me care whether there are tabs or spaces in this file!" If it's significant whether a line is indented with a tab or space, then that rule is broken, and you're probably in for a bad time. (Case in point: Makefile syntax).
I did not take this in consideration, because for such code, with brackets and separators, I prefer to align the separators with the opening and closing brackets, like this:
I just checked, and lining up the | with the open parentheses does work in modern F#. I believe they revamped the indentation rules a few years back, because I definitely remember things like that not working back when. So perhaps now your idea would be feasible. However, there was definitely a time in the past when F#'s indentation rules would have been problematic for tabs, and that fact is why the F# compiler still forbids tab characters outside of string literals or comments. (And there are still indentation styles recommended, though not required, by the official F# style guidelines that would require the use of spaces. Which is another reason to avoid tabs in F# code, because they're less flexible than spaces. Usually the reason to prefer tabs is because they're more flexible, but the slightly-peculiar nature of F#'s indentation rules means tabs are less flexible in F# code.)
>Because then you just hit that key binding, then press `>` or `<` — or Tab/Shift+Tab if you are using an inferior editor ;-) — until the indentation is where you need it.
But that's cumbersome compared to moving the block of code and hitting Tab to have your superior editor immediately indent the block at the right level.
IMO the biggest downside is that it gets awkward to do closures and inline expressions and things like that. For example Python's `lambda` and if-else expression which are super weird and special snowflakey compared to the equivalents in e.g. Rust or OCaml or even Tcl.
Maybe there's a way to do it nicely; I haven't thought about it too much.
Well yes. Say you check out a project that's all tabs but your editor is using spaces for indentation. You change a line and now the program is broken. Calling the auto-formatter won't help you.
Yes, Chez Scheme is fast but it took a lot of time (a few years!) to make the compiler translate Rhombus/Racket code to fast Chez Scheme code. And there are still a few rough corners to fix...
Also, Matthew implemented flonum unboxing to make code that uses a lot of floating points like x10 faster. I added type recovery, that gives a 10% boost in many cases. And I'm probably missing a few similar features.
In most cases the Chez Scheme team also was involved. Those changes were upstreamed, so you can enjoy them in Rhombus, Racket and Chez Scheme.
Once you have a bicameral syntax*, is there much point left in formal language theory? For instance, why would you still need complicated notions like LR(k) grammars (which Wikipedia confuses with LR(k) parsers)? I ask out of genuine confusion: I've been reading about formal grammars, and have even added to Wikipedia - but I'm still puzzled as to why PL designers might choose to have hard-to-parse syntaxes. Why don't people instead adopt an intermediate syntax like Rhombus's shrubbery notation†?
"Modern programming languages reflect a consensus on the the most important programming concepts, including lexically scoped variables, closures, objects, pattern matching, and type parametricity. Why, then, yet another programming language?"
I don't want to be too nitpicky but ... the sentence has two "the", aka "the the most important". It is a really irrelevant error, but on the other hand, has nobody ever read the documentation through slowly, before publishing? Because then this means lack of care and interest. Again, people make typos, that's ok, but if you try to promote a new language, you should at the least have read your own (!!!) writing once. And I am quite certain that the author has not bothered to check his own primary writing here, not even once. So why would he then expect others to want to use a new programming language? Sure, that typo means nothing at all about the programming language itself, but as I got older I also realised that many great language designers are horrible at writing documentation. I'd much rather use languages that are very well documented. Naturally this is a tiny issue here, but if you don't even care about typos in the primary introduction, it makes one wonder about the long term focus of the language as such.
Thanks for the report. I just made a PR to fix it.
I was not involved in writing this, but in my experience it's better to edit the text in Google Docs or something similar that catches all these easy typos. But it's harder to collaborate and make it git friendly, so I guess they just used a standard editor that has less support for this kind of errors.
I wonder how much utility of such special-purpose languages will keep getting diminished as AI coding becomes a staple in programming and software engineering.
With current LLM I am not sure. Using macro, you can often spare a lot of explicit code boilerplate. So token efficiency. On the other hand, will LLM shine in such a paradigme, where picking the right abstraction is more useful than generating large amount of lines?
Maybe it's a lake of training set, but just roaming the fine article, it already mention a LLM generated project which is more looking like Java idiomatic rather than something authors would consider elegant Rhombus code.
I’ve written a little library Rhombus.
I think my favorite thing is the `…` operator. Go check it out. It’s not like the splat operator in other languages, though it does give that feel initially. It’s much more general: it works with nested data structures and can take the place of a `map` operation.
The best part of `…` is that it is not a built-in thing—it’s just a macro! The magic is that Rhombus lets you define different macros depending on whether or not the macro identifier appears in binding context (left side of `=`), expression context, or some other contexts. IIRC you can even define your own contexts too.
Rhombus takes the best-in-class macro system of Racket and somehow finds a way to improve upon it. I say this after researching and comparing detailed metaprogramming features across a dozen different languages. Rhombus is a very neat little language.
Last thing: Rhombus’ main data type, the list, is implemented with an RRB tree. RRB trees support structural sharing, functional updates, and have O(log n) iterate, insert, delete, append, and arbitrary read operations. The constant factor on that is tiny: I think it’s like log_16 or log_32. They’re designed to be very cache friendly. Super cool data structure.
> I say this after researching and comparing detailed metaprogramming features across a dozen different languages.
I’m very interested in this. What was your research approach? Are there resources you can recommend beyond the documentation for individual languages?
Here's the paper I wrote: https://lambdaland.org/files/2024_ecoop_type_tailoring.pdf
Lots and lots of documentation, some experimentation, and asking people. :)
Thanks!
Finally someone uses the rrb tree as their main data structure! I implemented it for c# and the performance tradeoff compared to List<> was smaller than i had thought.
https://github.com/bjoli/RrbList/tree/main/src/Collections
Interesting.
Just a little nitpick on the repo root: "This is not the readme you want, Please go to the src directory." => But there is no readme in src directory
Thanks! I havet always been linking to the Collections subdir so I have missed this dumb issue. Will fix next time I use a computer. Might be some time though.
If you have any questions about the trees, feel free to ask.
> I think my favorite thing is the `…` operator. Go check it out.
I appreciate your enthusiasm. But three dots are really hard to google. Can you provide a link?
Some info here: https://docs.racket-lang.org/rhombus-reference/Repetitions.h...
That's both extremely neat and, for the time being, extremely hard for me to get my head around. I got it round monads, so I imagine it's just a matter of time!
> I think my favorite thing is the `…` operator. Go check it out. It’s not like the splat operator in other languages, though it does give that feel initially. It’s much more general: it works with nested data structures and can take the place of a `map` operation.
Something akin to `destructuring-bind' in Common Lisp?
I was not very involved in this. I still prefer s-expressions.
Anyway, my main initial concern was how to make good macros without s-expressions. There is a nice video by Matthew Flatt in RacketCon 2023. The first 6 minutes and 20 seconds are internal stuff, so skip to the 380s that I added in this link: https://www.youtube.com/watch?v=OLgEL4esYU0&t=380s He takes like another 6 minutes to explain the general idea and make some wishes, and then at the 12m mark he defines macros in Rhombus and makes the wish real in just 2m (with some enhancements later).
I mean, M-expression was proposed right from the start.
Then there is nothing special about having the brackets around. To start with, text can be just as readable:
And one can use stack base syntax, or define a static default arity to infix notation, example two, so `times plus 1 2 3` is not ambiguous and is really clearly like (1+2)*3 with such a convention. Then you can shift arity with reserved word so `unary plus 1` is like `+1` or `arity 5 action one two three four`, or going back to explicit marker like `(` and `)` or `do` and `go` to group stuffs without explicitly quantified numbering.
Feedback:
"Modern programming languages reflect a consensus on the most important programming concepts, including lexically scoped variables, closures, objects, pattern matching, and type parametricity. Why, then, yet another programming language?"
I love this as a start. More programming languages need to start the conversation this way.
However, it whiffs after this when it fails to answer the question. Or at least fails to answer it in a way I understand. The next paragraph should not start with "Beyond the basics, there are still more good ideas for programming constructs than can fit in any one language specification." - cut straight to what the "programming constructs" are.
This section ends with "approachable" and "extensible". These are nothing. When considering the reasons for a language, look at the negation. Nobody writes a language to be "unapproachable"... well, unless you're on the esolang wiki, but that's not really what we're talking about here. Nobody really wants to stick "non-extensible" on their language either... where we all disagree is in the how one extends things. As someone reading this screen to decide if I'm interested these attributes mean nothing to me.
The page does get around to making it clear that there is a huge focus on macros, which is something, but it takes a while to get there.
That's a legitimate selling point. It's especially a selling point if you can explain clearly how this is different from just using Scheme directly. I have no idea if your language does this but I've long thought that it would be interesting to have a macro-focused language that went all-in on making them debuggable. Have the language compiler and runtime support dynamically exploring them, expanding them in your editor, re-contracting them, full debugging support, just go all-in on supporting that work flow. That would be an example of that sort of thing.
Welcome to the Racket stepper: https://docs.racket-lang.org/stepper/
...and the Racket syntax-parse macro system: https://docs.racket-lang.org/syntax/stxparse.html
> When considering the reasons for a language, look at the negation. Nobody writes a language to be "unapproachable"… Nobody really wants to stick "non-extensible" on their language…
And yet, unapproachable languages and non-extensible languages exist. More specifically, there are languages where approachability and extensibility formed no part of the design goals and it shows.
Related. Others?
Summer Rhombus picture competition 2026 - https://news.ycombinator.com/item?id=48546270 - June 2026 (2 comments)
Rhombus Language - https://news.ycombinator.com/item?id=43394881 - March 2025 (158 comments)
Rhombus: Macro-extensible language with conventional syntax built on Racket - https://news.ycombinator.com/item?id=41151439 - Aug 2024 (97 comments)
State of Rhombus (programming language) - https://news.ycombinator.com/item?id=30314109 - Feb 2022 (17 comments)
I'm coming from Go, so apologies in advance if these questions seem a little weird:
How do I distribute my Rhombus programs? Can I cross compile to other architectures/OSs, ideally with a static binary?
What about libraries? Is there a good package manager? I presume from the post that the library ecosystem is pretty immature (maybe the Racket ecosystem is larger). Can I easily build a CRUD web app?
Is concurrency easy to make correct? Are tests easy to write? Tests involving concurrency? Race detection?
Dev experience: is it statically typed? I couldn't really tell from a quick search. Will the build system make a fast feedback loop for me and LLMs? Is it IDE friendly (auto complete, find all references, etc)? Is there language server support so I can bring my own editor? Will the macros mean I have to learn a bunch of DSLs to use anyone's library? Do the DSLs have IDE support?
Wow that's a lot of questions ;) It looks like a fun language in any case. And the fact that its even possible to make a Pythonic language on top of a LISP is its own showcase for Racket's power
> How do I distribute my Rhombus programs? Can I cross compile to other architectures/OSs, ideally with a static binary?
You can compile them inside DrRacket and distribute the .exe or equivalent. I used that a few times to send programs written in Racket to coworkers that are not programmers (remember to add an icon so it looks professional).
You can use the command line too, and it support cross compiling, but I never used it https://docs.racket-lang.org/raco-cross/index.html
> What about libraries? Is there a good package manager? I presume from the post that the library ecosystem is pretty immature (maybe the Racket ecosystem is larger).
Some libraries have been ported to make them more idiomatic, in particular changing the name of the functions and fixing the different meaning of "list". Anyway, you can import any library of Racket from Rhombus and vice versa https://docs.racket-lang.org/rhombus-guide/Modules.html
> Can I easily build a CRUD web app?
Sorry, I never tried.
> Dev experience: is it statically typed? I couldn't really tell from a quick search.
It's optional. You can add statically types when you want and the code will be more efficient and get compile time errors. Or avoid them and get run time error.
> Will the build system make a fast feedback loop for me and LLMs?
Sorry, I never tried.
> Is it IDE friendly (auto complete, find all references, etc)? Is there language server support so I can bring my own editor?
auto complete: no (I think)
find all references: yes
> Will the macros mean I have to learn a bunch of DSLs to use anyone's library? Do the DSLs have IDE support?
Most macros try to blend with the language and be invisible, but it's possible to write weird and bad macros too. Most libraries should not define weird macros.
Anyway, some internal parts of Racket like `for` or `match` are implemented in Racket and are like two complete DSLs on their own.
Thank you! I appreciate your taking the time to reply
You can read about Shrubbery, just adding the Rhombus syntax in Racket:
https://docs.racket-lang.org/shrubbery/index.html
What with the term itself, is that some monthy python reference or related to tree algebraic structure?
Matthew Flatt picked “shrubbery” because it’s tree-like but not fully expanded, so it tends to be more broad/flat than deep like a tree. Hence also the term “enforrestation” when you fully expanded it.
I think the Monty Python reference is just a happy coincidence.
Nice to get so much insightful feedbacks. That's the kind of exchange that make HN still sometime interesting.
The knights who say Ni demand a shrubbery.
More like the Knights who say Nil
I'd love to get a talk on this at the 2027 Carolina Code Conference (polyglot and cybersecurity). Call for Speakers will open in January.
https://carolina.codes
Looks like a real conference - but the first thing you see is a large image of Rick Astley ?!
We do a "Lyrical Code" T-shirt where people submit song lyrics as code in their favorite language and then we pull verses from different languages to make a polyglot t-shirt. Last year at the conference, attendees voted for Never Gonna Give You Up as this year's song.
2023 - Don't Stop Believing
https://github.com/brightball/carolina-code-conf-lyrical-cha...
2024 - Bohemian Rhapsody
https://github.com/brightball/carolina-code-conf-lyrical-cha...
2025 - All Star
https://github.com/brightball/carolina-code-conf-lyrical-cha...
You can see the final version of the shirt here.
https://blog.carolina.codes/i/148154944/youre-an-all-star
We're a little low on PR's this year unfortunately though. I don't know if it's all the AI or something else but we usually have about a dozen entries by now and we've only got 2 for some reason this year.
Rhombus is designed to be
* approachable and easy to use for everyday purposes, with a readable indentation syntax; and
* uniquely customisable with an _open-compiler API_ that is accessible to a wide audience.
Racket is already approachable and easy to use for everyday purposes
A lot of people hate sexprs. Even seemingly reasonable folks.
I imagined they have met students that really struggle with the syntax, while grokking the concepts easily.
I myself have heard "the parentheses are hard to balance" and "after a while you dont even see the parentheses" enough times that I think maybe both can be correct.
My editor balances my parentheses (Emacs Paredit). I rarely think about them. I just think structurally and the editor manages the details.
It really feels like, "when I move through the wasteland, I only focus on the path and GPS is guiding me well".
For some reasons, people tend to prefer having a walk in a forest rather than in z wasteland.
Look, if you’re committed to Blub, don’t let me talk you out of it.
> when I move through the wasteland
You got that exactly backwards. A non-lisper unavoidably has to deal with tons of syntactic and semantic clues - parens, colons & semicolons, square brackets, indentation & white-space, special chars, static type annotations, lsp servers and tree-sitter parsers. Lisp only needs two things - a [small] set of structural idioms, and a live REPL.
> A lot of people hate sexprs
In all my time I have never come across a single Lisper, neither in person nor online, and I know far more than a few dozens, who once grokked the REPL-driven workflow and the structural editing idioms only to later, for whatever reason, suddenly start disliking or even hating s-expressions.
All that so-called "hatred" stems from unfamiliarity. People fuss about Lisps lacking static types, without a single clue about how a "true" REPL trades them off for something different. They compare it to a Python or C# REPL and think "it ain't a big deal". Well, the Lisp REPL is quite different, and yes, a major deal - every single part of the Read-Eval-Print-Loop differs. They complain about "hard to deal with parentheses" and "I can't refactor without types" while having no clue how amazingly nice structural editing is in practice, that you never even think about parens - you only see structure, order and reason.
well, i guess i know what the grandparent was talking about when they said 'I myself have heard [...] "after a while you dont even see the parentheses" enough times [...]'. Thanks for the example.
As I said, i think they have been teaching long enough to have a pretty good basis for the claim that racket's syntax can be a problem.
I am firmly in the "after a while you don't see the parentheses" camp, but I have a friend who I respect a lot who works in clojure (with Emacs/cider/paredit) that just doesn't like it.
I mean, I prefer sexprs above all other syntaxes, and I have had people tell me I just need to get used to indentation syntax or whatever they fancy.
> In all my time I have never come across a single Lisper, neither in person nor online, and I know far more than a few dozens, who once grokked the REPL-driven workflow and the structural editing idioms only to later, for whatever reason, suddenly start disliking or even hating s-expressions.
And we've never seen bullet holes in these parts of the plane, so there's no point putting armour there.
It's not about survivorship bias, it's about notation. It's like "hating Leibniz's dy/dx because Newton's dot notation already exists" and I'm arguing that people don't just "hate the notation", they simply misunderstand the principles of calculus. I'm not saying that notation preferences don't have consequences, but in this case, I've seen far too often the evidence that programmers ignore the underlying ideas outright, simply because they didn't like the notation on first sight.
This is survivorship bias. People who don't like s-expr aren't lispers.
I've used Lisp before. I can read s-expr code. Unfamiliarity is not the issue. I just don't like them. I don't like Haskell/ML either, and I've written large projects in both, so it's not a Lisp-specific thing.
Considering your experience and preferences, what do you like?
> I just don't like them
That is what I don't get. I have used many different languages, and often is not the syntax that I don't like - I may dislike the semantics, the runtime, the tooling, but syntax, really how? It's like "I hate Greek alphabet", even though this is a weird comparison - alphabet is a flat bag of arbitrary symbols with no structural role, so disliking it sounds incoherent by construction. I just can't ever get over "s-expressions hate", in such a way like: "What are you even talking about? There's practically zero syntax in Lisp."
That's precisely the issue: there is only one syntactic form. Everything blends together and ends up looking the same. It makes my eyes hurt.
I have quite the opposite effect. I don't "hate" programming languages, but honestly, sometimes I don't understand how the fuck we (people) managed to build layers and layers of complexity (both syntactic and semantic) for things that can be concisely and simply explained as simple Lisp forms.
I get bonkers hysterical laughs sometimes, grabbing a piece of Java, Typescript or Python and asking an LLM how a similar code would look in Clojure. That doesn't universally yield "better" results; sometimes, the code may look certifiably more cryptic than the original - brute-forcing an algorithm into Lisp can look very terse, but that's up to the coder - I am capable of writing cryptic yet functioning code in any language.
I love Lisps, ML-family languages, etc. Languages like Java or Go are just painful for me to program in, and I know I’m probably in the minority there.
But honestly, I think a lot of it comes down to the fact that syntax carries semantic expectations. Certain syntax makes you expect a certain model of programming: mutability, imperative control flow, objects everywhere, etc.
Gleam is a good counterexample. It has an ALGOL-ish syntax, but semantically it’s a functional language, and it’s wonderful to read/write.
Same with Ruby: the parts of Ruby that still make me smile are mostly the parts that feel Lisp-adjacent.
It’s kind of wild that we live in a world where, for most programmers, syntax seems to matter more than semantics.
> syntax carries semantic expectations
True! Syntax is a signaling system. Braces and semicolons signal the C-family, so you prepare for statements, mutation, sequential side effects, and objects. Parentheses-first signals Lisp, so you expect recursion and macros. Significant whitespace signals Python. Before you have read a single semantic line, the notation has already established a prior expectation. That is real, and most language discourse ignores it.
But syntax carries more than semantic expectations. It signals era, tribe, tooling, and aesthetics too. The paren signal says Clojure, CL, Emacs, REPL, niche, old-and-proud as loudly as it says functional. Some of the aversion to parentheses originates from sociological resistance to these signals rather than from semantic concerns. Yet honestly, grokking Lisp can make a true polyglot out of a coder. It did it for me. "A Lisper" is not always someone who writes and reads Lisp full-time. Fully fluent Lisper can rationally and successfully use any other PL syntax, because they understand the semantics, even though they'd actively try optimizing the connotation and ergonomics layer, a genuine separate axis.
I think if you believe that the aids types give for refactoring are equivalent to structural editing, then you are the one who might not get the value of typing information (I say this as a Python person, and am totally willing to accept lack of typing info in plenty of situations)
REPLs are nice and good, but when you're working on large enough systems it's nice to have some static foundations for your facts.
I don't "believe" things, I pragmatically choose the tools that work, the ideas that have merits. I did not say "refactoring is equivalent to structural editing", and I specifically talked about comparing Python REPL to Lisp's.
I don't lack experience working with type systems, I have used over a dozen different PLs, some of them were weirdly unusual - I once even had to program in a language with all operators in Russian.
> when you're working on large enough system
I have built and supported sufficiently large systems in various languages, and have seen firsthand the trade-offs Lisp systems can bring. The holistic experience of using Clojure often can beat systems with advanced static types, but you probably won't ever notice it, because you'd first demand something to "believe" in.
You guys (replying to the comment) seem to be convinced of my one-sided bias for defending s-expression syntax and dying for it. I'm defending it only because it gets bad rap from people unfamiliar with the merits. REPL-driven workflow, live image, structural editing, homoiconicity, code-as-data - none of these require the surface syntax to be parens and Rhombus is the living proof. Structural editing operates on any AST. The actual jewel is homoiconicity, and sadly it gets largely ignored by the majority of programmers today. S-expressions probably are the simplest form of syntax to operate homoiconic entities - the simplest notation that is at once a fully explicit tree and directly the language's own data structure. "I love homoiconicity" does not uniquely entail "I love parentheses", alas, programmers off the bat hate parentheses, often without even attempting to understand their significance - they think it's "aesthetic choice". They don't even for a second look around and get curious for why people keep making new Lisp dialects, 70 years on.
It's not unreasonable to dislike coding in s-expression syntax. It is not very readable.
There's a reason the vast majority of programming languages (especially weighted by popularity) use more traditional syntax.
> It is not very readable.
That holds true only for two cases:
- For a programmer who never learned Lisp as their first language. I have met people who learned Clojure as their very first PL and they said it was fun. Later there were utterly confused about Java, Python and Javascript. Going the opposite may feel confusing and identity-breaking.
- Reading static code. In a sense, it can be a bit harder to read a wall of Lisp, say printed on paper. Lispers typically don't inspect "dead code" like that; they'd connect to the live REPL and eval expressions on the go, programming it from "inside out". With experience, it becomes easier to scan the code and mentally parse it. Lisp at that point actually gets far more readable than any other PL. For instance, Lisp code is better suited for smaller screens of smartphones - the code wraps around yet retains its readability. Try that trick with literally any other language, I can 100% guarantee - most of them would look like a huge pile of indecipherable mess.
> For a programmer who never learned Lisp as their first language
Maybe. But I have never heard anyone say that Python is hard to read, and it's one of the most common complaints against Lisps. Just looking at them both it's hard to imagine how one could seriously believe that s-expressions are more readable. `(== a b)` is clearly worse than `a == b`. Even JavaScript programmers know that.
> they'd connect to the live REPL
Yeah I dunno this is the same cop-out Ruby programmers use to justify its lack of static typing. It's fundamentally better if you can understand code without having to run it.
> `(== a b)` is clearly worse than `a == b`
It's clearly worse just because it moved from infix to prefix and is wrapped by parens? Is `(* (+ a b) (+ c d))` clearly worse than `(a + b) * (c + d);`? Both have a bunch of parens, and one even has a semi colon.
This works both ways. `(list 1 2 3)` is clearly better than:
It's also better than `var l = [1, 2, 3];`
How often are you trying to make sense of a bunch of infix arithmetic operations when you're programming? Separately, how often are you creating data structures, navigating data structures, handling data in the form of JSON or XML, parsing that data into your language's native data structures, etc.?
Reading arithmetic in prefix instead of infix is easy, even if it is counter to how you were taught in elementary school. Working with s-expressions for code and data is clearly better than whatever syntax your language uses for code and either directly instantiating data or reaching for JSON or XML.
> justify its lack of static typing
Racket has both Typed/Racket as well as contracts.
you could also compare
if (a === b && b === c && c === d && d == e)
To scheme's
(= a b c d e)
JavaScript clearly has the upper hand.
For you, perhaps. I've never been able to get into lisp style sexpr syntax languages :'(
)
There matched your paren for you.
Don’t you know that :’( is actually a trigraph for meta-quote-expression·opening ? Such a a reckless move as a lone mere literal closing bracket could destabilize the cosmic equilibrium entirely!
Being in the Lisp family, an often heard criticism is its use of parenthesis (disclaimer: I understand the difference between syntax & semantics. But syntax does matter).
Is this an issue in Rhombus? Or Racket?
I agree 100%. Racket is Awesome.
The Rhombus implementation is about 70% Racket!
Adding significant whitespace to a new language feels like a bad choice. It's not terrible but I do think it was a bad call for Python in hindsight.
why do you think it was a bad choice?
It‘s a source of problems with mismatched tabs/spaces being used for indentation between team members for fairly little upside. Imo it also makes moving blocks of code more cumbersome.
Shrubbery, Rhombus's first-pass indentation-sensitive syntax, has a syntax form to facilitate copy-paste.
With guillemets, « and », you can make a section of Shrubbery code indentation-insensitive. The idea for copy-paste it to "armor" the section you want to copy with guillemets in the right places, and unarmoring it after posting.
This needs editor support to do fluidly, but imo it's much better than trying to copy-paste the indentation-sensitive syntax.
The Guillemets syntax is described here: <https://docs.racket-lang.org/shrubbery/group-and-block.html#...>
I can't tell from my 5 minutes of poking DrRacket whether it supports this "armoring", I've been writing Shrubbery in nvim, which, unsurprisingly, does not support it.
That's horrifying.
At least it shows that the authors are aware of this issue and planned for it.
Any language with significant indentation ends up specifying "Indent with spaces, not tab characters" for just that reason. As I recall, Python had that as a recommendation while F# ended up with it as a requirement, but it's been a while since I looked at that so I could be wrong. But in my experience, the category "people who complain about significant whitespace" is nearly a subset of the category "people who prefer tabs over spaces for indentation".
(Moving blocks of code around is not a real problem if your editor is capable of easily highlighting the thing that was just pasted. Because then you just hit that key binding, then press `>` or `<` — or Tab/Shift+Tab if you are using an inferior editor ;-) — until the indentation is where you need it. I haven't found it to be a big problem in practice when writing Python, though mileage will likely vary).
For me, the alternative solution makes much more sense for a language with significant indentation, i.e. to use only tabs for indentation and to completely prohibit spaces before the first printable character of a line.
I do not know why I have never seen this solution in practice.
It depends on the language's indentation requirements. That can work in Python, where you never need to line things up with characters above that aren't a multiple of an indent level. But in F#, at least a few years ago when I tried it, there are times when you would need (or strongly want) to line things up with other characters. For example, this example from https://learn.microsoft.com/en-us/dotnet/fsharp/style-guide/...:
Note how the | needs one extra space in order to line up with the word "function", due to the open parenthesis. If you're using tabs for indentation, that means you need a series of tabs plus one trailing space after the tabs, in order to line up the | correctly.
Any situation where you must have a mixture of tabs and spaces for code to work right leads to a nightmare. Because it makes you have to turn on visible whitespace in your editor and peer closely at the lines. I have a simple rule: "Do NOT make me care whether there are tabs or spaces in this file!" If it's significant whether a line is indented with a tab or space, then that rule is broken, and you're probably in for a bad time. (Case in point: Makefile syntax).
I did not take this in consideration, because for such code, with brackets and separators, I prefer to align the separators with the opening and closing brackets, like this:
or
I just checked, and lining up the | with the open parentheses does work in modern F#. I believe they revamped the indentation rules a few years back, because I definitely remember things like that not working back when. So perhaps now your idea would be feasible. However, there was definitely a time in the past when F#'s indentation rules would have been problematic for tabs, and that fact is why the F# compiler still forbids tab characters outside of string literals or comments. (And there are still indentation styles recommended, though not required, by the official F# style guidelines that would require the use of spaces. Which is another reason to avoid tabs in F# code, because they're less flexible than spaces. Usually the reason to prefer tabs is because they're more flexible, but the slightly-peculiar nature of F#'s indentation rules means tabs are less flexible in F# code.)
>Because then you just hit that key binding, then press `>` or `<` — or Tab/Shift+Tab if you are using an inferior editor ;-) — until the indentation is where you need it.
But that's cumbersome compared to moving the block of code and hitting Tab to have your superior editor immediately indent the block at the right level.
That's why you use an autoformatter.
IMO the biggest downside is that it gets awkward to do closures and inline expressions and things like that. For example Python's `lambda` and if-else expression which are super weird and special snowflakey compared to the equivalents in e.g. Rust or OCaml or even Tcl.
Maybe there's a way to do it nicely; I haven't thought about it too much.
You can't autoformat broken indentation with significant whitespace since it would make the program not parse (or parse incorrectly)
I was responding to
> mismatched tabs/spaces being used for indentation between team members
Well yes. Say you check out a project that's all tabs but your editor is using spaces for indentation. You change a line and now the program is broken. Calling the auto-formatter won't help you.
Massive fail. I dread having to move code around my F# codebase.
At least here they provide an alternative syntax that does not need significant indentation, so a program structure may be written on a single line.
I may be over-sensitive to looks but... god why ?
would be prettier. (I guess authors had to compromise in affecting symbols)
https://rhombus-lang.org/performance.html
Thanks to Chez Scheme I guess...
Yes, Chez Scheme is fast but it took a lot of time (a few years!) to make the compiler translate Rhombus/Racket code to fast Chez Scheme code. And there are still a few rough corners to fix...
Also, Matthew implemented flonum unboxing to make code that uses a lot of floating points like x10 faster. I added type recovery, that gives a 10% boost in many cases. And I'm probably missing a few similar features.
In most cases the Chez Scheme team also was involved. Those changes were upstreamed, so you can enjoy them in Rhombus, Racket and Chez Scheme.
No instances of blazingly detected in the paragraph "is it fast ? ", I guess the answer is not very
Like 3-5 times slower than C or Java. This is similar to my rule of thumb for Racket. More details and benchmarks in https://rhombus-lang.org/performance.html
Once you have a bicameral syntax*, is there much point left in formal language theory? For instance, why would you still need complicated notions like LR(k) grammars (which Wikipedia confuses with LR(k) parsers)? I ask out of genuine confusion: I've been reading about formal grammars, and have even added to Wikipedia - but I'm still puzzled as to why PL designers might choose to have hard-to-parse syntaxes. Why don't people instead adopt an intermediate syntax like Rhombus's shrubbery notation†?
* - https://parentheticallyspeaking.org/articles/bicameral-not-h...
† - https://docs.racket-lang.org/shrubbery/index.html?fam=Rhombu...
"Modern programming languages reflect a consensus on the the most important programming concepts, including lexically scoped variables, closures, objects, pattern matching, and type parametricity. Why, then, yet another programming language?"
I don't want to be too nitpicky but ... the sentence has two "the", aka "the the most important". It is a really irrelevant error, but on the other hand, has nobody ever read the documentation through slowly, before publishing? Because then this means lack of care and interest. Again, people make typos, that's ok, but if you try to promote a new language, you should at the least have read your own (!!!) writing once. And I am quite certain that the author has not bothered to check his own primary writing here, not even once. So why would he then expect others to want to use a new programming language? Sure, that typo means nothing at all about the programming language itself, but as I got older I also realised that many great language designers are horrible at writing documentation. I'd much rather use languages that are very well documented. Naturally this is a tiny issue here, but if you don't even care about typos in the primary introduction, it makes one wonder about the long term focus of the language as such.
Extremely poor reasoning to assume that an author, upon reading his own primary writing once, is guaranteed to catch a typo of this nature.
Thanks for the report. I just made a PR to fix it.
I was not involved in writing this, but in my experience it's better to edit the text in Google Docs or something similar that catches all these easy typos. But it's harder to collaborate and make it git friendly, so I guess they just used a standard editor that has less support for this kind of errors.
Haven't tried it, but isn't collaborative editing what the zec.dev people are working on?
I wonder how much utility of such special-purpose languages will keep getting diminished as AI coding becomes a staple in programming and software engineering.
With current LLM I am not sure. Using macro, you can often spare a lot of explicit code boilerplate. So token efficiency. On the other hand, will LLM shine in such a paradigme, where picking the right abstraction is more useful than generating large amount of lines?
Maybe it's a lake of training set, but just roaming the fine article, it already mention a LLM generated project which is more looking like Java idiomatic rather than something authors would consider elegant Rhombus code.
Indentation scope? Pass.