Big fan of Cap'n'Proto and this looks really interesting, if RPC is the thing that works for your use-case.

However, stumbled over this:

The fact is, RPC fits the programming model we're used to. Every programmer is trained to think in terms of APIs composed of function calls, not in terms of byte stream protocols nor even REST. Using RPC frees you from the need to constantly translate between mental models, allowing you to move faster.

The fact that this is, in fact, true is what I refer to as "The gentle tyranny of Call/Return"

We're used to it, doing something more appropriate to the problem space is too unfamiliar and so more or less arbitrary additional complexity is...Just Fine™.

https://www.hpi.uni-potsdam.de/hirschfeld/publications/media...

Maybe it shouldn't actually be true. Maybe we should start to expand our vocabulary and toolchest beyond just "composed function calls"? So composed function calls are one tool in our toolchest, to be used when they are the best tool, not used because we have no reasonable alternative.

https://blog.metaobject.com/2019/02/why-architecture-oriente...

▲

KuSpa 3 days ago | parent | next [-]

Ah, the good old squeak/smalltalk days. A few years back I worked on signals (or rather a static analyser for the editor to support signals) in squeak/smalltalk. The kind of signals those indie frameworks like angular and svelte now adopt trying to solve the problem of changepropagation you outline in your paper.

What i'm getting at is: For the places where other tools are better (like the UI example), we already have other tools (signals, observables, effects, runes,...). And for the places like client/server-communication: This is kind of where "call/return" usually shines.

	▲	mpweiher 2 days ago \| parent [-]
		> And for the places like client/server-communication: This is kind of where "call/return" usually shines. The WWW would like a quick word with you. CORBA as well, if it could get a word in. > we already have other tools (signals, observables, effects, runes,...) We can build them. We can't express them. We can also build everything out of Turing Machines, or Lambda Calculus or NAND gates.

▲

kentonv 3 days ago | parent | prev [-]

Eh, I think composed function calls have legitimately won _because_ they compose well and are easy to understand, not just because we haven't tried other things.

▲

mpweiher 2 days ago | parent [-]

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

2. You are making an invalid assumption, which is that we only get to have one tool in our toolbox, and therefore one tool has to "win". Even if function calls were the best tool, they would still not always be the right one.

With the benefit of hindsight, it’s clear that these properties of structured programs, although helpful, do not go to the heart of the matter. The most important difference between structured and unstructured programs is that structured programs are designed in a modular way. Modular design brings with it great productivity improvements. First of all, small modules can be coded quickly and easily. Second, general-purpose modules can be reused, leading to faster development of subsequent programs. Third, the modules of a program can be tested independently, helping to reduce the time spent debugging.

However, there is a very important point that is often missed. When writing a modular program to solve a problem, one first divides the problem into subproblems, then solves the subproblems, and finally combines the solutions.

The ways in which one can divide up the original problem depend directly on the ways in which one can glue solutions together. Therefore, to increase one’s ability to modularize a problem conceptually, one must provide new kinds of glue in the programming language.

-- John Hughes, Why Functional Programming Matters

https://www.cse.chalmers.se/~rjmh/Papers/whyfp.pdf

via

https://blog.metaobject.com/2019/02/why-architecture-oriente...

3. Procedure calls are not particularly composable

See CORBA vs. REST.

▲

kentonv 2 days ago | parent [-]

> 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.

	▲	mpweiher 2 hours ago \| parent [-]
		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...