▲ | mpweiher 2 hours ago | |
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 [5] https://2019.splashcon.org/details/splash-2019-Onward-papers... |