|
|
Re: Back at OOPSLA
|
Posted: Oct 26, 2006 2:07 PM
|
|
Everybody is missing the ball on this. Distributed computing involves a *network*. This means that an execution model that uses streams, pipes or similar queued transfers will work well with distributed computing. Objects don't use queues, they use a stack for messages. Stacks and queues are different models. Asking why stacks don't work well as queues is rather strange to me.
If objects would ditch the stack model for messages, then you could get somewhere, unfortunately you would need to ditch the idea of methods/functions.
Messages in OOP use a stack even in its abstracted form, and its effects are profoundly felt. To prove it, consider that you cannot send another OOP message before you get a response unless it's a nested message. This means that the first message I send is the last from which I will receive a response (from any active message). First in, last out. Exactly like a stack. Threading just creates more stacks. That solves nothing. And functional programming is stack based too, so although functions at the same level can occasionally execute at the same time, don't expect much help with functional programming either.
A network on the other hand is first in, first out. If I send a file over a network, the first byte that the destination will receive is the first byte that I sent. This is first in, first out. That's a queue.
Note that although half of an OOP message transaction can be queue based, the obligatory return path corrupts any distributed possibilities as well as any queue or streaming model, mostly because the sender must wait (something that is completely against concurrency). So OOP messages should work with simple things, but anything complicated will become a mess.
Note too that Map/Reduce are streaming constructs (first in, first out), not a functional one as most people incorrectly think. That (streaming) is why they're successful in distributed environments. Too bad this promotional argument of Map/Reduce that is often used in support of functional programming is actually a vote against it. Map/Reduce spits in the face of functional programming.
So your question becomes why doesn't a stack based data processing model fit a queue based data processing model? Well, that's rather obvious. I have no problem streaming Unix apps over a network. Anyone who's done video processing knows the streaming method well and uses many machines to get the final audio/video output with many of them working at the same time. You can even process multiple videos in a pipeline fashion where each device processes a different video. Strange that streaming works well over networks, but not stacks, eh? Strange that hardware with it's input/processing/output streaming mechanism works, but not objects, eh?
The no silver bullet paper talks about comparisons between software and hardware. I can't talk about the conclusion, but I guarantee that the reasoning behind the "No Silver Bullet" paper are dead WRONG! Hardware uses streaming. Software uses stacks. Streams scale, stacks do not. End of story.
|
|
Previous Topic
