> As a co-author of the reactive manifesto I'd like to point out that >> "reactive" can be considered a superset of "async". Good reactive >> applications are event driven and non-blocking. They are also responsive, >> resilient, and scalable which async can help with but does not prescribe. >> >> What are the "bad connotations"? I'm curious to understand other >> perspectives on this. >> > > I would say the opposite. Asynchronous or not >happening, moving, or > existing at the same > time<http://www.learnersdictionary.com/definition/synchronous>< > does not necessarily imply non-blocking. It simply emphasizes that "things" > might coexist without an explicit dependency (in a time dimension) on each > other. At the same time (pun not intended) > reactive<http://www.learnersdictionary.com/definition/reactive>limits itself > to responding to events which implies a control by some sort > of FSM. Perhaps concurrency could be modeled using FSMs, but I do not > believe it is always a simple transition. >
Our use of language in the technology industry could, for sure, be better. Take simple examples like RAM where random should be "arbitrary", or don't get me started on people who misuse the term "agnostic" ;-) Synchronous is now understood to be making a call in a blocking fashion with an optional return value. What is actually missing is the following implied word, i.e. communication. We are normally talking about synchronous communication or asynchronous communication but the "communication" part gets dropped. Good traits/qualities in critical systems are to be responsive, resilient, and scalable which is at the heart of the reactive manifesto. Many techniques can be employed to achieve this. One such technique that has yet to be bettered in my experience is to be event driven and non-blocking. This is very much how the real world functions. We all have our own private models of the world that we share with message passing, or events given your chosen nomenclature. As an aside I believe FSMs are a very useful tool that more developers should have in their toolbox. If they are observable in implementation then even better. They have been totally invaluable whenever I've done any work on highly-available systems. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
