Folks, Arguing technical details here misses the point. For example, a different conversation can be started by asking Why does my web hosting provider say I need an FTP client? Already technology is way too much in my face and I hate seeing programmers blame their tools rather than their misunderstanding of people.
Start by asking yourself how would you build these needs from scratch to bootstrap something like the Internet. What would a web browser look like if the user didnt need a seperate program to put data somewhere on their web server and could just use one uniform mexhanism? Note I am not getting into "nice to have" features like resumption of paused uploads due to weak or episodic connectivity, because that too is basically a technical problem -- and it is not regarded as academically difficult either. I am simply taking one example of how users are forced to work today and asking why not something less technical. All I want to do is upload a file and yet I have all these knobs to tune and things to "install" and none of it takes my work context into consideration. Why do I pay even $4 a month for such crappy service? On Jun 11, 2012 8:17 AM, "Tony Garnock-Jones" <[email protected]> wrote: > On 9 June 2012 22:06, Toby Schachman <[email protected]> wrote: > >> Message passing does not necessitate a conceptual dependence on >> request-response communication. Yet most code I see in the wild uses >> this pattern. > > > Sapir-Whorf strikes again? ;-) > > >> I rarely >> see an OO program where there is a "community" of objects who are all >> sending messages to each other and it's conceptually ambiguous which >> object is "in control" of the overall system's behavior. >> > > Perhaps you're not taking into account programs that use the > observer/observable pattern? As a specific example, all the uses of the > "dependents" protocols (e.g. #changed:, #update:) in Smalltalk are just > this. In my Squeak image, there are some 50 implementors of #update: and > some 500 senders of #changed:. > > In that same image, there is also protocol for "events" on class Object, > as well as an instance of Announcements loaded. So I think what you > describe really might be quite common in OO *systems*, rather than > discrete programs. > > All three of these aspects of my Squeak image - the "dependents" > protocols, triggering of "events", and Announcements - are encodings of > simple asynchronous messaging, built using the traditional > request-reply-error conversational pattern, and permitting conversational > patterns other than the traditional request-reply-error. > > As an aside, working with such synchronous simulations of asynchronous > messaging causes all sorts of headaches, because asynchronous events > naturally involve concurrency, and the simulation usually only involves a > single process dispatching events by synchronous procedure call. > > Regards, > Tony > -- > Tony Garnock-Jones > [email protected] > http://homepages.kcbbs.gen.nz/tonyg/ > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
