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