What is on Your Mind?

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....

Hi mikemazz...

Satisfy my curiosity...

I, as a complete novice, am wondering why is shell scripting considered _complete_hell_ from your POV...

It is said that "there is more than one way to skin a cat" and shell scripting gives just that proverb's choice.

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.

Hi, mikemazz.
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.

I agree with very little of what you wrote.

Best wishes ... cheers, drl

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

Regards,
Alister