I've been reading to learn about tech for over a decade. It used to be the case that anything that didn't make sense was a sign that I'm a dumb baby and need to learn more. As I progressed and started exploring beyond dense technical tomes for knowledge, I've learned the hard way that other people's standards for what they would publish online in a professional capacity are lower than I assumed. They could actually just be talking out of their asses. That if a webpage is full of buzzwords written loftily, the purpose is to dupe me, regardless of whatever the distilled 1-paragraph version of that would say.
There's nothing like the fiery, strident rhetoric of a <i>manifesto</i> to get one's heart pounding.<p>"Application requirements have changed dramatically in recent years."<p>I mean, if <i>that</i> doesn't make you want to lose your chains, I don't know what will.
I like the broad idea (applications should be very responsive). Yes, this is very important, but I can't shake the feeling that the author of the manifesto has very little experience with responsive software (or even with software generally).<p>For example, the manifesto confuses ends with means. It states a desired end, but then claims that certain means are required to get there (for example, "event-driven"). Maybe event-drivenness can come into play in a given system, maybe it shouldn't; across a broad set of domains this is orthogonal to the concept of responsiveness.<p>In video games, for example, we do things that are extremely responsive compared to web stuff (last week I worked on something that had to run at 200 frames per second in order to meet requirements). Interactive 3D rendering systems are most certainly <i>not</i> event-driven; they derive their responsiveness from cranking through everything as quickly as possible all the time.<p>There are lots of different domains of software out there and they all have found different local attractors with regard to what techniques work and produce the best result. Web software is just one of these domains, and frankly, it isn't doing so well in terms of quality compared to some of the other ones. So I think if one wants to write a manifesto like this, step one should be to get out of the Web bubble for a while and work hard in some other domains in order to get some breadth and find some real solutions to return with.
I made a new diagram they can add to this "manifesto" if they like - <a href="http://i.imgur.com/ll51WJ3.png" rel="nofollow">http://i.imgur.com/ll51WJ3.png</a>
My first reaction to reading this? If you follow this design in the way that they say, you're going to wind up with a confusing mess with no visibility into why your buzzword compliant application is dog slow.<p>Very carefully thought out and pervasive monitoring is an under-acknowledged but utterly essential part of Google's recipe for success.
"It works best if the compartments are structured in a hierarchical fashion, much like a large corporation where a problem is escalated upwards until a level is reached which has the power to deal with it."<p>Because when I think "effective, responsive, and scalable decision-making", I <i>definitely</i> think "big ol' ORG CHART", amirite? /snark
This talk by Jonas Bonér (one of the Akka devs) covers the motivations behind this well: <a href="http://parleys.com/play/51c0c876e4b0d38b54f461f6/chapter0/about" rel="nofollow">http://parleys.com/play/51c0c876e4b0d38b54f461f6/chapter0/ab...</a>
So basically... Tcl. Which got all of that years and years ago. Except of course 'scaling', which doesn't make a lot of sense for the desktop environment it was created in. Actually, come to think of it though, it did get that too, via AOLServer.
Horses for courses. Async. architectures are great for distributed back-end systems (God I love making streaming data-science applications) ... but not so great for on-the-metal embedded devices; where static & limited computational capacity & whole-system predictability requirements drive you in the opposite direction. I do a lot of machine vision stuff for embedded systems, and having everything driven by the drum-beat of a frame interval really does simplify things a lot; particularly when it comes to finding the absolute cheapest hardware that will be able to perform a given function.
Apparently written for the sole purpose of feeling superior to the 95% of all developers who's applications in no way, economical, practical or otherwise, justify such architecture astronautics.<p>Yes, there are applications that needs this, and I love to read about them, and learn from them. From real world solutions for real world problems that is. Not via some arrogant abstract this-is-the-one-true-path manifesto.
I found out that a build I was doing was utilising <a href="http://imgur.com/U70Rcrz" rel="nofollow">http://imgur.com/U70Rcrz</a>. I don't see that very often.
Personally I find that kind of parallel processing CS magic impressive.
Similarly I like the possibility of processing data as it arrives in a non blocking fashion in pipes-and-filters chains of computation.
Another thing I like are having arbitrary numbers of stateless possibly short lived servers. Like you see at PaaS's like Heroku. Easy load balancing, easy recovery.
These are all things that become possible by employing other programming paradigms than the classical thread based, blocking, stateful ones.<p>And it's not confined to one tech stack either; .net, javascript, java, scala, ...<p>To me it's just good computer science for when you want to be near real time, scale horizontally and utilise your hardware resources and be able to handle failure.
Some thoughts about manifestos in general:<p>"A manifesto is about moral authoritarianism: an absolutist statement of eternal values from which follows (typically) an absolutist ideal of the good life. If there is one thing that most defines a manifesto, it is what it lacks: a central place for uncertainty."<p>"The problems Haque identifies cannot be solved with manifestos because they are problems, not karmic punishments for espousing false values that will go away through the embrace of the “right” values."<p><a href="http://www.ribbonfarm.com/2013/11/13/the-gooseberry-fallacy/" rel="nofollow">http://www.ribbonfarm.com/2013/11/13/the-gooseberry-fallacy/</a>
here is my manifesto: react to everything and you're slave. create reactions and you're ruler. balance action and reaction and you're a master.
Nice moment for the pioneers, such as Joe Armstrong. Seems like they finally got understood. There would be no Scala without Erlang and no such paradigm without Martin Odersky. I am happy and grateful that I could read their books and use products of their efforts.