Infering that this is the main purpose of the LSP and that it is therefore the devil and the worst thing ever is not only polemic, but wrong.
-
-
(And also, what would be the corresponding increase in complexity of the control logic.)
-
If your API is designed for potentially high latency (which is a good practice in many cases anyways), and you have a language-native client that wraps the IPC, there is no reason writing client code would be more difficult to write.
-
However the server code would be much more complicated to write. It's also much more complicated to debug and reason about from the perspective of the client. Additionally, the OS must task switch to the server process which in itself has a significant latency and cost, and back.
-
This also means you'll have to carefully design the API to too many calls, which means the API is both harder to design and use, and less flexible. When the result is meant to be presented to the user it's easy for the overhead/latencies to stack up and you can no longer hit
-
60/144FPS. So you'll spend more time refining the API to add more caching (which is really complicated to get right) and bulk-functions or you'll just do as most seem to do nowadays, "meh, 200ms is fast enough for opening a dialog".
-
That being said, server/IPC is surely the right tool for some jobs, but it's a really bad tool for solving interop.
-
Agree that it is better for some applications more than others. Still curious to hear about an alternative that promotes interoperability and works across OSes.
-
Not my area of expertise. I'm mostly concerned with the attitude that any solution to a problem is a good solution. E.g. docker is imho very commonly used only because deploying PHP/Python/etc is a nightmare, whereas compiling to binary would be far more ideal.
- 20 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.