Please, I beg you, �Stop!� Yes, stop writing scripts and instead build workflows.
Programmers, Sys-Admins, System Support, I'm talking to you.
Ok, I know in this community I'm going to get some serious backlash for my statements but I truly believe in my statement.
There was a time when writing scripts to help support IT infrastructures and changing business processes was the best option. That time is gone. Todays computing systems are rapidly growing in complexity and the need for easier integration and better automation to manage these systems is becoming paramount.
�So where do we go from scripts�?, you ask. �That is the right question�, making reference back to the movie �iRobot�.
I believe the answer is workflow and workflow automation. I don't think this is the right forum to share all the reasons for my answer so let me take another approach and talk about why script fail.
If you are an IT professional, you most certainly have written a script or two in your time. Scripts are written to automate tasks with the general objective to be more productive and reduce errors. In the early stages of an organization or while its environment is small, writing a few scripts seems to add benefit and meet its objectives. However, over time the environment changes, grows and becomes more complex. This results in more tasks, which in turn requires the need to write more scripts. Soon, the ability to manage these scripts themselves becomes overwhelming - welcome to script hell.
AND...
To put it briefly scripts:
1) Have little or no security
2) Lack of reuse
3) Not cross-platform
4) Hard to maintain
I can't say I entirely agree with this. We have a directory full of python scripts (~ 15 MB) and they are magnificently modularised (and documented). Well written and highly reusable.
Could you please elaborate on this. (May be give an example, if possible)
Will depend of the quality of the writing...and the person's knowledge and experience
For a company's point of vue, you get what you pay for... A truly experienced UNIX sysadmin script will not look the same as the one writen by a "highly qualified" IT consultant that left IT college 3 years ago with a 6 month shell class ...
Certainly, there are individuals, groups, and organizations - like you - that will work hard to write good clean reusable scripts. And if you are primarily a Python shop then it makes that easier. Most of the time, when I tell people, "Stop Writing Scripts" it's to stop writing shell scripts. There is always a place for higher-level language scripting like Python.
To comment about workflow and workflow automation. I've spent a good part of my career designing and writing automation systems. And that's my primary focus today. I would recommend reading my blog post.
Workflows allow you to work at a higher abstraction layer. It let's a user focus on what they really need to accomplish by providing a great deal of the heavy lifting. It removes the need to understand things like: how can I run this on 10 computers, what if I need elevated privs, should I be logging for auditing purposes. Maybe a visual will help:
Over the top. You are making many assumptions and of course you are making several incorrect statements. With that said, nothing wrong with putting together your own "world"... as long as it works and is well supported. So if you believe a python workflows (or whatever) is the "right answer", certainly you are free to do that. If you believe a workflow paradigm is the way the world should be crafted (even if not python based)... again, you are free to do that. There are many ways to solve problems. So I have no problem with a workflow paradigm.... but solutions should be able to implement whatever style best fits the situation.
I will never tell someone to stop writing scripts. Python, shell or otherwise.
Btw, it's a valid argument to say that Python is a lower level language than (Bourne) shell script. Just saying.
If I am going to have to write something that requires the complexity of a work flow, I am not going to write a script. I am going to write something that is an executable to take make it efficient in terms of computing resources. The complexity of the scripts you suggest are generally written with a work flow built in or some sort of logic beyond the requirment of a script. Take for example, the Nagios tool. It is a collection of scripts and it has an underlying work flow. I am not a fan of scripts that are complex, even with work flows.
Telling us to stop writing scripts is silly. There is "script hell" and then there is "architecture hell", when well-meaning environment designers deny you the ability to use something they think you don't need. Take away the shell and your users are forced to invent silly ways to hack it back in.
Control methods are always useful of course. What about existing, common workflow languages like make ? Much-abused, but at its core, uses very simple "destination:source" rules which I think can be used simply and effectively for lots of things.
This argument seems to be flawed from the beginning.
"Scripts" is just a certain form of the more general "program". You either can explain the difference between these two (which is hard to conceive, because any commonly-used programming language today is Turing-complete or Turing-equivalent) or you have to admit that your assertion extends to "stop writing programs". While this may or may not convey a cultural benefit*) it certainly will not help the IT business within the parameters of its todays operation.
Workflows can never replace programs, for the same reasons why programs cannot replace workflows: programs are ways of automatically executing certain actions in a predefined way within computers. Workflows are quite the same but within organisations. They work on different (and ideally complementary) levels. While they regularly work hand in hand - given, with more or less success in attuning to each other - there are things a workflow cannot do (because it is happening inside a computer) and things a program cannot do (because it is happening in some organisational part). To try and replace one by the other is futile.
You might want to try and replace the OS on your computer (which is just another program) with a (any) workflow if you do not believe me. Chances are you end up with a non-functional computer and a non-functional workflow as well.
Just my two cents.
bakunin
__________
*) Programming, once considered to be and practised like an art is done like a craft today. This has an IMHO negative impact on programs and programmers alike. Compare the masterpieces of, say, Beethoven and the jingles used in commercials, compare a statue of Michelangelo to the design of a disposable bottle to understand the difference between something done as an art and something done as a craft.
Once we had programmers like Donald Knuth, who took a ten-year sabbatical just to create an adequate typesetting system for his book "The Art [sic!] of Computer Programming" - we all know TeX. Compare this way of dealing with emerging problems in completing ones task with the usual "we have to meet the milestone deadline next Tuesday"-approach. That does not only take different types of persons and different types of mindframes, that also results in different types of programs. Arts versus crafts....
Different tools for different purposes.
You will have difficulty explaining to clients that they have to wait for your workflow to be finalised, when the requirements can be met by just scripting it. And it doesn't even have to be a one-off: it can be embedded in a workflow later where it can be completely encapsulated (blackboxed).
Equally, I will not necessarily show sympathy when someone else argues a workflow is the best solution, where I know a script will do it.
I suspect it's not to do with the shell scripting itself but the management of it. "There's a bunch of script files on server x left by admin z, nobody knows what they do" kind of thing.
Which doesn't make shell scripting the problem as much as the lack of documentation...
Somehow making it all visual doesn't strike me as actually solving it. Whether it's text or diagrams, you have to know the tools.
Wikipedia isn't a definitive source, but it seems to me that scripts easily fit the description above.
Researchers, experimenters, students, hobbyists all use scripts effectively.
I find that scripts are one the most reusable solutions to problems precisely because they are portable among platforms.
Long scripts, badly written, without comments are hard to maintain. So might be spaghetti diagrams, text descriptions, and the highest of high abstract languages.
Your histrionic lead-in to a post bereft of concrete examples suggests that, instead of a genuine technical discussion, your primary goal is the promotion of your automation product. The fact that the post is cobbled from a blog promoting your product is not a surprise.
"The more they overthink the plumbing, the easier it is to stop up the drain."
-- Montgomery Scott