How Rholang relieves the burden of a syntax-semantics gap in programming

In an interview with Epicenter, Greg Meredith and Nash Foster broke down one of the key things that makes Rholang unique where other programming languages are lacking due to what can be called a syntax-semantics gap. Nash explained that the simplicity of some languages is deceptive. “You can stand something up and it will sort of work, but you’re going to have a lot of bugs because you don’t really understand what you’re doing. The model of computation is too confusing.
“The thing about Rholang is that the entire language fits on an index card, so you can show someone the entirety of Rholang in about 15 minutes. Syntactically, it’s far simpler then Solidity, JavaScript, or any practical modern language, but it has all the power of those language at its fingertips. It’s really easy, and because it’s compositional, it’s really easy to begin with something you can understand completely and thoroughly, and then build on top of that by building components that interact in ways that you have solid intuitions about. This is very difficult, if not impossible, in modern programming languages that don’t have the benefit of the rho calculus.”
“If you’ve written code in PHP or JavaScript, you’ve debugged the problems that occurred because the model of computation actually implemented, and what you think it implements, are different. That’s the feeling you get when you’re staring at a chunk of code and it looks like it does what you want, and somehow when you run it, the program doesn’t do at all what you wanted. You can’t understand why it’s doing what it did. What you’re feeling right then is the gap between the syntax and the semantics of the language…the thing about Rholang that’s so amazing is that the semantics came first, and Greg did a great job of boiling the semantics down to the smallest possible set of rules, and the syntax is built directly on top of those. There’s a one-for-one correspondence, so your intuition about what the program syntax says and what it actually does is very, very clear. It’s very hard to get confused about what your program is actually doing.”

Greg added, “To amplify Nash’s point, even if we’re talking about a strongly typed language that has been bashed on by industry and had lots and lots of commercial code deployed on it like Java, the reality is that Java is a part of a family of languages where, when you’re staring at the code, not everything is in the code. Not everything that results in the execution of that program is in the code. It’s not in front of you. You also have to keep in your mind the stack, the threads that are active, and a whole bunch of other stuff that’s not on the page, which means the programmer’s mind is burdened. There is this cognitive load that’s not supported anywhere on the page. There are models of computation — the lambda calculus was the first one of such and then pi calculus and languages like that were the second such, where the structure-function relationship between what you see and how it executes, everything is on the page. That’s another thing that makes it easier for programmers. When you’re looking at Rholang code, you don’t have to keep something else modeled in your head. You can offload that down to the page. Just look at the page, and reason about what’s in front of you. So it’s actually easier rather than harder.”
To see a further explanation with simple examples, see Rholang vs. the dining philosophers.