3 ms·

I understand you want nobody on your lawn...and i'm sure newsql/nosql is just IMS again...and you have an opinion that either functional or OOP sucks. They're

I understand you want nobody on your lawn...and i'm sure newsql/nosql is just IMS again...and you have an opinion that either functional or OOP sucks. They're all tools / approaches. In general, each has several perfectly valid applications. I've used RPC in the past and it was a great approach (a fairly standard XML-RPC interface). Would it have been better as REST with JSON? Probably...at the time REST and JSON didn't exist (late 90s). It certainly felt better than CORBA. From a naive perspective of someone greater than 25, bridge looks interesting. I would expect some (not all) others who have "been there" would feel the same. I don't think the hyperbolic condescending attitude is really called for. I apologize if I'm inferring incorrectly the tone of your post. EDIT: corrected a typo

mcguire 14y ago
RPC is one of the few things that qualifies for my Big List o' Evil. It's not that it doesn't work at all; that would a completely different issue. The problem is that it seems to make a lot of things simpler, right up to the point where it forces a massive amount of its own complexity on you. RPC is not a "leaky abstraction"; it is semantically invalid. It makes network messaging look like function calls of some style. But they aren't. (At some point, you will find yourself asking what happens when the remote procedure completes successfully, but the calling side gets an error. Or spend some time wondering why some simple code is so slow before you realize that it's spending a millisecond on network transmission to do a tiny fraction of that time's computation.) If you ever see the claim that you can write your code normally and then decide how to distribute it, run away screaming. Or picture me doing it for you. It doesn't work. When you build a distributed system, the fact that it is distributed, and how it is distributed, are an order of magnitude more important than everything else. If you're using it to make communicating between languages easier, then yes, that is a big win. But there are other ways to do that. REST and JSON are relatively new, but textual protocols like HTTP and its figurative ancestor, SMTP, aren't. And if that's not good, there's always IETF block diagrams and network byte order. But, you're saying, I'm doing RPC right, structuring my systems around the communications and relying only on large-grained, asynchronous calls. That's great, but what exactly is RPC buying you at that point? 'Cause it's costing you at least visibility into the communications. My first question for anyone using bridge is this: what happens when you have 3 clients calling code on a server, which in turn is calling a couple of other servers, and those servers are making calls back to the original server.

mcguire 14y ago

RPC is one of the few things that qualifies for my Big List o' Evil. It's not that it doesn't work at all; that would a completely different issue. The problem is that it seems to make a lot of things simpler, right up to the point where it forces a massive amount of its own complexity on you. RPC is not a "leaky abstraction"; it is semantically invalid. It makes network messaging look like function calls of some style. But they aren't. (At some point, you will find yourself asking what happens when the remote procedure completes successfully, but the calling side gets an error. Or spend some time wondering why some simple code is so slow before you realize that it's spending a millisecond on network transmission to do a tiny fraction of that time's computation.) If you ever see the claim that you can write your code normally and then decide how to distribute it, run away screaming. Or picture me doing it for you. It doesn't work. When you build a distributed system, the fact that it is distributed, and how it is distributed, are an order of magnitude more important than everything else. If you're using it to make communicating between languages easier, then yes, that is a big win. But there are other ways to do that. REST and JSON are relatively new, but textual protocols like HTTP and its figurative ancestor, SMTP, aren't. And if that's not good, there's always IETF block diagrams and network byte order. But, you're saying, I'm doing RPC right, structuring my systems around the communications and relying only on large-grained, asynchronous calls. That's great, but what exactly is RPC buying you at that point? 'Cause it's costing you at least visibility into the communications. My first question for anyone using bridge is this: what happens when you have 3 clients calling code on a server, which in turn is calling a couple of other servers, and those servers are making calls back to the original server.