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.
* 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.
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.
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.
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 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 just don't like them
That is what I dont get I have used many different languages. and often is not the syntax that I dont 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 cant ever get over .sexpressions hate. in such a way like. What are you even talking about. Theres practically zero syntax in Lisp.
You didn't say it directly, but it's implied from what all you said in this thread, just as no one in this thread said "outright unreadable". Up until now, there's no acknowledgement of the downsides and you refuse to even understand the dissenting point of view. If you truly do acknowledge the downsides, you would (try to) understand why people "hate" it. But no, "people are too incoherent to not like the beautiful perfection of s-expressions" as the lines in between would say.
Save the time and resources spent on learning (let's for the sake of the argument imagine we get it for free), there are zero downsides to reaching fluency in a foreign language. Zero. Sure, one still may prefer reading Tolstoy, Bulgakov and Dostoevsky in English, even though they'd probably agree - to unveil the full gamut of emotions, it needs to be read in Russian, simply because there are tons of interesting twists of phrases that are just inconceivable to be translated precisely. Same can be said about English - James Joyce's puns and phonetic play just don't port well; Beckett's rhythmic English is delicate; Carroll's wordplay and Victorian logic-games in "Alice" are extremely English-specific.
Alas, learning a natural language to fluency may take a lifetime. That's why we don't go around screaming "Learn Spanish if you want to understand Borges, Márquez and Cortázar!". Yet at the same time, nobody in the right mind would ever join a discussion only to say "I hate Spanish, it's weird and hard to read".
And just like there are no downsides to acquiring a natural language (once again, let's say you get it free - ignore the time cost), there are really no big drawbacks to getting fluency in Lisp. It is universally better to know it (even if you don't use it every day) than not knowing it at all. Lisp teaches you that most syntax is noise. Once you internalize that, you write better code in any language because you're not cargo-culting idioms - you understand why they exist.
I'm not saying Lisp is universally better than the alternatives. I'm just saying that it has tremendous value, and the "haters" are just missing it out.
And just like I won't ever trust anyone claiming they dislike a language despite enormous fluency, I just can't see how anyone would know Lisp and yet just hate it. I stand by my words; the bias and hatred come from misunderstanding. I understand why programmers may dislike a specific PL - but Lisp is not a single programming language. It's an idea, the idea that influenced pretty much every single PL being used in the industry today. Like I dunno, how could anyone hate recursion, or closures, or pattern matching, or parametric polymorphism - these are just ideas, specific tools to use in specific context and situation. The only reason I see someone may hate them is because they have not gained sufficient understanding for how they work.
Assuming any such comparison is valid is purely speculative. There are significant differences.
> anyone who reaches fluency in a foreign language just "magically" stops hating it.
Not true (plenty of people learn Mandarin and regret doing so), and even if it were true it could just be survivorship bias - of course people who hate a language are less likely to become fluent in it.
> Turns out they don't really hate the language, do they? They don't hate phonology, morphology, syntax - they "hate" the culture, the idioms, the orthogonal stuff, right?
No, sometimes people really do hate the language.
> nobody in the right mind would ever join a discussion only to say "I hate Spanish, it's weird and hard to read".
That might not be a productive thing to say in a discussion, but that doesn't mean it can't be true.
> Like I dunno, how could anyone hate recursion, or closures, or pattern matching, or parametric polymorphism - these are just ideas, specific tools to use in specific context and situation.
Plenty of people hate any or all of those things. I'd say it's reasonable to hate a tool that tends to have bad consequences - e.g. a language feature that makes code superficially easier to write but hard to refactor or debug.
Oh come on. You're flummoxed about things that are not controversial. You don't have to listen to some rando HN commenter like me - there isn't a line-up of renowned CS figures or prominent programmers who ever harshly criticized Lisp to absolute rejection, even Dijkstra. People expect him to have bashed Lisp, but he actually praised it (and not once): "Lisp has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts." And there's a long line of well-known names from Alan Kay to Steele, Matz and Goetz, etc. who publicly said great things about the grand idea of Lisp. That is all well-documented and known. This isn't some "recorded history of the past", it's still going on - Clojure-like languages for different runtimes popping up every few months. Lisp isn't BASIC, Fortran or COBOL, yet some people waste so much energy to prove to themselves that it's somehow "wrong" or has "bad consequences", while Apple, Cisco, Netflix, Walmart, CircleCI, Nubank and many others have successfully built and maintained large projects. All the while so many "opposing" ideas quietly died over the years - Ada's intended universal dominance; anti-GC dogma; Algol 68 complexity-heavy direction (though Algol's good ideas lived on); rigid, ceremony-heavy, anti-interactive approaches consistently faded, while the dynamic/interactive/symbolic cluster that Lisp has pioneered keeps getting re-adopted.
What serious programmer ever ignores Lisp influence or importance? I suppose an ignorant one. I get it, plenty of serious programmers acknowledge the influence and still rationally choose not to use it, but outright rejecting the idea because it doesn't "visually appeal to them" - that is some naivete.
Whatever. You free to hold any beliefs - my actual, pragmatic, lived experience says otherwise.
About the ideas, yes, helped by being such an early language that it can lay claim to being the originator of a great many things. About the syntax, rather fewer.
> Apple, Cisco, Netflix, Walmart, CircleCI, Nubank and many others have successfully built and maintained large projects
There are a great many success stories and just as many failure stories. 60+ years on, Lisp continues to exist but remains niche.
> rigid, ceremony-heavy, anti-interactive approaches consistently faded, while the dynamic/interactive/symbolic cluster that Lisp has pioneered keeps getting re-adopted.
Yes and no; the pendulum swings but the oscillations get smaller. At this point the programming world has pretty much converged on present-but-lightweight typing with inference and optional annotations, for example; there are no new serious pure dynamic languages being made, and all major dynamic languages are putting huge effort into retrofitting typing. Long edit-deploy-test cycles aren't coming back but nor is live-editing your production system.
> What serious programmer ever ignores Lisp influence or importance?
That's quite a different thing from saying that it's pleasant or even good. Every serious critic acknowledges that e.g. David Foster Wallace was influential and important, but many openly hate actually reading his work.
> actual, pragmatic, lived experience
Hardly. You've built this a whole edifice of beliefs that wouldn't withstand 5 minutes outside the Lisp bubble.
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.
And we've never seen bullet holes in these parts of the plane, so there's no point putting armour there.
Ok but where is the dot notation? If this is the only notation available for those ideas, how can you be sure that it's the ideas that are the problem and not the notation?
> 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.
Then why are you opposed to people presenting the ideas with different notation, if the ideas are what you think is valuable?
What are you talking about? I'm not opposed to anything, I don't know where that conclusion comes from. I'm just trying to explain why people hate s-expressions. Because of the unfamiliarity. I remember the time before I convinced myself to give Lisp a try - I'd look at it with all my previous knowledge of other programming languages and just didn't see it. I thought it was "unreadable", "weird", and had no merits in the "modern" world of computing. I was convinced that Lisp is archaic and there's no practical reason to use it. I was wrong on all counts. Learning Lisp and using it in real projects made me appreciate programming more, it taught me things that I haven't imagined before, my only regret that I didn't do it sooner.
You seemed to be implicitly claiming that there was no point presenting the ideas with a different syntax.
You're making very strident claims based on very little evidence. Maybe you're right, but I think we should at least entertain the possibility that people who think they hate s-expressions actually do hate s-expressions - which would be an ample explanation for why those people never got into Lisp.
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 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.
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.
For some reasons, people tend to prefer having a walk in a forest rather than in z 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.
There's a reason the vast majority of programming languages (especially weighted by popularity) use more traditional syntax.
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.
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);
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.
Yes.
> `(list 1 2 3)` is clearly better than ...
It's not better than `[1, 2, 3]` is it?
> How often are you trying to make sense of a bunch of infix arithmetic operations when you're programming?
Very often??
Anyway it isn't just the lack of infix that makes it difficult to read - there's also the crazy bracket matching, and the lack of syntax in general. Yes that is a strength when writing parsers, macros and so on, but it also definitely hurts readability.
If you want to change your vector to a linked list, in Lisp, you can change from `(vector 1 2 3)` to `(list 1 2 3)`. If you have some array `[1, 2, 3]` and you want to change to a linked list for whatever performance concern, you'd have to replace `[1, 2, 3]` with..
var list = new List();
l.insert(1);
l.insert(2);
l.insert(3);
`(date 2026 6 1)` is better than "2026-06-01" because the latter isn't a date, it's a date string. `(date 2026 6 1)` is better than `new Date(2026, 6, 1);` because the former is how it is serialized and can be deserialized.
> there's also the crazy bracket matching
At least with reading code, there is almost no reason to try to match brackets at all. It's like complaining about having to read semi-colons in languages that use them to signify the end of a statement. When writing code, Lisp is just another language like all the rest that benefit from an IDE that is syntax-aware. Having highlights for the starting paren and ending paren for an expression and being able to just select a particular expression make bracket matching fairly effortless.
if (a === b && b === c && c === d && d == e)
To scheme's
(= a b c d e)
JavaScript clearly has the upper hand.
I already pre-empted that: readability tracks what you learned first and how much you've practiced, and you trying to restate the familiarity effect as if it refutes it. You're measuring familiarity, not intrinsic readability. If you ask people about less popular language, say Haskell, yeah, they'd complain about its "readability" too.
> most common complaints against Lisps
Well, they are wrong on the other side of the fence. There are thousands of Lispers who'd say exactly the opposite, that: "Lisp is by far more readable than anything else"
You're cherry picking some fictive example about syntax, well, it's not a convincing one, comparing more than just a and b, blows up quickly, innit? `a === b && b === c && c === d`, while in Lisp it remains uniform `(= a b c d)`.
Lisp just uses one rule everywhere. "One uniform rule" vs "prefix for functions, infix for some operators, with a precedence table". You ever thought about that? You think you're getting an aesthetic point for binary operator example, while disregarding a bunch of layers that scream "simplicity".
> is the same cop-out Ruby programmers use
It's not the same, you clearly speaking as someone without honest, heartfelt attempt to use any modern Lisp dialects, like Clojure, Fennel or Jank. Honestly, try using Clojure, (re)write some personal shell scripts in babashka. It's truly great, and I'm saying that as someone who has used different languages, varied in paradigms. Interactive eval is not a substitute for static checking and I never offered such stance. Not to mention the enormous amount of research and experimentation on type systems that's been done by Lisp communities.
There matched your paren for you.
The Rhombus implementation is about 70% Racket!
Is this an issue in Rhombus? Or Racket?
Rhombus is a novel notation (that is implemented as a Racket macro) which eliminates the need for almost all parentheses. They have a handful of code snippets on their homepage.
[1] Racket doesn't distinguish between parentheses and brackets, so programs could be paren-free. In practice, brackets are only used in a few key places: https://docs.racket-lang.org/reference/if.html#%28form._%28%...
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.
(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).
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.
I do not know why I have never seen this solution in practice.
functionName
arg1
arg2
arg3
(function
| Choice1of2 x -> 1
| Choice2of2 y -> 2)
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).
( ...
| ...
| ...
| ...
)
{ ...
; ...
; ...
; ...
}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.
> mismatched tabs/spaces being used for indentation between team members
It's really not an issue at all in practice. The issue of making moving code more awkward is true but really barely an inconvenience. It's not difficult to select it and press tab a couple of times.
As I said the biggest issue is with closures and expressions that you might want on one line.
Tell that to the one team at my old workplace that used spaces for all their scripts.
Like I said it’s a stupid source of errors that can be mitigated through style guides and tooling but it’s still a source of errors.