> The WWW would like a quick word with you regarding function calls having won.

Nope, HTTP got it wrong. HTTP was designed to fetch files -- GET and PUT. It's fine at that. REST was invented as a way to shoehorn APIs into the model of HTTP. It's a weird model that's very different from regular programming, and people have a really hard time thinking about it. But some people argued that REST is the "right way" because it fits into this HTTP model that was never designed to support APIs in the first place. And other people said "yeah that makes sense" and went along with it.

Enormous amounts of effort are spent implementing REST APIs that wrap underlying programming language APIs, and then writing client libraries that implement the programming language APIs again on top of REST primitives.

It's all a waste. If the industry had taken a different path and focused on network protocols that model programming language APIs all along, I think we'd be in a much better place. Better late than never, though.

> 3. Procedure calls are not particularly composable > > See CORBA vs. REST.

I never personally used CORBA, but I have a lot of experience building big distributed systems on Cap'n Proto and I've found it far more composable than REST.

Hi Kenton,

Thanks for that reply, I’ve never seen my thesis from Can programmers escape the gentle tyranny of call/return[1] expressed so perfectly.

Let me explain: First, I think we are in violent agreement that there is a mismatch between, for example, the REST architectural style of the WWW and the call/return architectural style that we have in most programs. An architectural mismatch that needs to be bridged with great effort. Second, we can probably also agree that the call/return architectural style is hard-coded into pretty much all of our so-called “general purpose” programming languages (C, C#, C++, Java, Rust, Swift, …). I call this architectural/linguistic mismatch.

And third, we as software developers are so used to this state of affairs, the we pretty much perceive “programming” to simply be “writing procedures/functions/methods”. Mary Shaw writes pretty much the same in Myths and mythconceptions: what does it mean to be a programming language, anyhow?[2]

So REST is not “wrong”, it is different from what we are used to. And it is also not “weird”, that is, again, a function of what we are used to.

And REST is clearly not “wrong” because somehow call/return is successful. The world’s largest software system, the WWW is built on REST. (And no, REST was not invented afterward to shoehorn something into something, REST is the architectural style of the WWW[3]).

When I saw teams writing ungodly amounts of code to wrap REST APIs in “nice” procedural APIs”, again and again, the waste also struck me. However, I took the opposite route: In-Process REST[4] uses REST to structure programs internally. The results were amazing whenever I applied it, partly because REST is much, much more composable than procedure calls. And that was in languages that did not support REST natively.

I then created a language that does support REST natively[4] and you get a nice concept of a Storage Combinator out of it[5].

[1] https://dl.acm.org/doi/10.1145/3397537.3397546

[2] https://dl.acm.org/doi/10.1145/3480947

[3] https://ics.uci.edu/~fielding/pubs/dissertation/abstract.htm

[4] https://objective.st

[5] https://2019.splashcon.org/details/splash-2019-Onward-papers...