This is a very useful discussion - thank you Rob for starting it. We both want and need this kind of feedback!
One of the observations that you noted wrt to the shell is that it has "its own language". Indeed there is a language here, in the same way that the wsk CLI already offers a language for serverless programming using OpenWhisk. When the language of the CLI is limiting, what do we do as developers? I posit that we layer new languages on top --- my favorite example is "give me the last activation". At one point I polled for how many bash aliases the community has come up with for this feature! Recently the wsk CLI added `wsk activation get --last`. That's still too verbose and I continue to use my local alias for this command and I expect others will too. More concretely, it's too verbose when I'm developing, iterating, and debugging. In the same way, I've seen developers share bash scripts for automating other tasks that the current wsk CLI (or really any client) doesn't yet support. For example: deleting all assets in a namespace, or a package. These are features I expect will eventually end up in the wsk CLI. But the gate for rapidly experimenting with new aliases, plugins, features is too narrow today. The "openwhisk shell" is a way of normalizing the programming experience for serverless - it does subsume the CLI in that the wsk commands should work inside it, but also extends the capabilities to add more syntactic convenience and make a workflow more fluid - some of these may not be readily possible or practical in a terminal. One of the benefits that I've experienced directly is that it makes the iterative programming experience and development for serverless more agile and fluid. To me, this is independent of the question of scripting for deployment, continuous integration, and delivery and hence the context for my "old school" comment - the shell can export a bash script for you, or other artifacts like a serverless framework manifest, for managing a deployment (as examples). -r
