keithb-

Okay, I'll bite. Analogies are not really helpful for software development. Comparing software development with building a house doesn't work and this comparison with foods doesn't work either. The problem is not in your mocks or your layers. Software development is about translating prose into code. Given that, it doesn't really matter if your shell is imperative or reactive because your job is translation not creation.

I had a feeling something was going astray when the examples were primarily about data access and I/O. Reactive is (at best) a framework for handling streams and events. CRUD events aren't a great place to start because you're only showing the happy path. What about sequencing? What about retry? What about conflict? I'm not questioning your concept; it's the application.

Reactive isn't a translation technique which is ultimately why these analogies fail. Sometimes I wish software engineers could have a Roy Fielding/REST moment where someone comes along and clarifies the purpose of software engineering by pointing out the fact that everything you need already exists. In lieu of that, I'm sure that people smarter than me will eventually abstract away the reactive boilerplate behind some language keywords because the alternative (i.e. more data access and service endpoint examples) is really tiresome.

Not trying to single you out (your statement is totally on point), but generally we need a word for this developer-centric view of Cloud. My kids write javascript and might be considered developers, but they don't have the faintest idea about operating systems, containers, services, or anything non-superficial in the stack let alone IAM, I18N, consensus, etc. Cloud is not any less of an operational model as it is a development platform.

Anyone else have to read "Madame Bovary" in high school? Maybe this focus on developer is a form of provincialism.

Come on: someone smarter than me must have coined this already.

This article may be inspirational to you, but it's not very well written or well argued. Is the California gold rush really an example of "sudden discovery of underutilized resources"? And isn't the subject of that sentence actually the technological changes that inspired the "major changes in economic patterns"?

Okay, so zero-sum games and scarcity economics are based on the idea that resources/valuables are limited and I'm all in favor of agreeing that there is no end to resources, creativity, or human sympathy. And I would even be willing to take that a step further and say that, no matter what the problem, there will be people willing to devote their time to it.

But the crux is not available resource: the key is defining something as a problem. Are schools the problem, or poverty? Are broken windows the problem, or mandatory minimums? Take away the assumptions from this article, and you aren't left with much more than a half-reasoned book report. I would be much more inspired if the conclusion of this article was something like "nuanced solutions are the only option" rather than what was presented: "be excellent to each other".

No, POST is create and PUT is update[1]. In the RESTful world, PUT uses a specific URL for that entity, e.g. PUT /contacts/rich-hickey: there is only one Rich Hickey and I'm going to update his contact info with the body of the request. Check out the Decision Flow Diagram, it is really awesome[2].

There is probably no single reason why you should never use POST when you need PUT or DELETE. This is mostly an implementation choice, but if you are using a Repository or DAO pattern on the server side, it might be easier to understand if all of the semantics align nicely, e.g. HTTP<POST> -> OOP<Add> -> SQL<CREATE>, HTTP<PUT> -> OOP<Update> -> SQL<UPDATE>.

IMHO using a parameter for method name is a call-by-name strategy that, in this case, is a level of abstraction that just isn't necessary. In other words, there is really nothing dynamic about the behavior. When the application state hits the client side, the flow of control is dictated by earlier events or actions. Your application isn't likely to make decisions on the fly about whether the current flow is concerned with creating an entity versus deleting an entity. For example, the user and the application state "know" already what is valid for an entity and it is likely that your application is reflecting that in a hard-coded "action=[add|update|delete]" parameter. Why funnel this state through a single method with a switch-statement on the server side?

Incidentally, there are some references to caching the results of a POST request[3] but I can't think of an production example that I've run across. It might be cacheable if the response is a redirect to the same "list of entities" URL rather than a direct URL to the newly created entity which is arguably more RESTful but not cacheable.

[1] http://restcookbook.com/HTTP%20Methods/put-vs-post/ [2] https://webmachine.github.io/images/http-headers-status-v3.p... [3] http://programmers.stackexchange.com/questions/114156/why-ar...

I tend to agree. I studied UML and earn certs. At the time, I really liked it and I had fun drawing diagrams for both new and existing projects. Now, I only use it for sketching and I think the vocabulary is the key: it is more important for you and your team to know the important terms than the nuances of the actual spec. For example, the transitions on activity diagrams have sophisticated semantics for describing events, functions, etc. that may be more cumbersome to document and explain than, for example, a label just saying "convert to binary".

In my career, I have only seen a few things that caused religious fervor on any significant scale: XML and UML. But I would like to know if the level of specification around these languages is the off-putting aspect or if it is something else. Did mathematicians of the Newton-Leibiz time exchange letters denouncing proofs or trolling with irreducible polynomials?

I agree with this sentiment. We don't need new, simpler languages to teach programming concepts; we just need a better approach to teaching. We don't skip teaching the English language to toddlers in favor of a simpler one. I learn "cat" before "encyclopedia" and "hungry" before "enlightened". Programming languages have similar levels of abstraction so one can start with basics and allow the growth/understanding/grok to come from exploring the depths of abstraction inherent within.

I think the intention here is to somehow reach a point where the understanding is complete. As if one can say "There, now I understand all of [insert programming language]." and tick off some item on their career progression or bucket list. It's simply not like that.

Let's not conflate this with the Holocaust even as a joke. Automation like this is a step forward even if it only inspires a dreary debate about economic theory.