I write many a PowerShell script for the organization I currently work for. Most recently I have been co-writing a tool that, in the end, will have a lot of functionality (beyond a single purpose), will be configurable, and will have both a CLI and GUI, all in PowerShell. So when does a script stop being a script and when can you call it an application or a program. Is this just kind of in the eye of the beholder?
-
9A program is what you give yo the audience, a script is what you give the actors. Beyond that, there is little difference. – May 23 '14 at 13:50
-
2Just because you can write a GUI in PowerShell, it doesn't mean you should. – OldFart May 23 '14 at 16:35
-
1@OldFart yea I know. We would have done it in C# but for some reason when our supervisors hear the word "compile" they have a conniption. At the same time we have to appeal to the lowest common denominator of knowledge. Rock>us<hard place – SomeShinyObject May 24 '14 at 01:09
-
@MichaelT I think about your quote every now and then and I laugh to myself, so this constantly begs the question, is this something you just came up with kind of extemporaneously or was this something you've heard before? – SomeShinyObject Oct 29 '14 at 13:45
-
2@ChristopherW it was a bit from a State of the Onion (keynote talk/lecture) by Larry Wall a number of years ago. Programming is Hard, Let's Go Scripting... The bit that I paraphrased from the talk in full is: "Suppose you went back to Ada Lovelace and asked her the difference between a script and a program. She'd probably look at you funny, then say something like: Well, a script is what you give the actors, but a program is what you give the audience. That Ada was one sharp lady..." – Oct 29 '14 at 16:55
3 Answers
A "script" is a set of instructions that do something the user could do themselves, only faster and with less possibility for error.
Sure, I could delete all my old log files manually, but the script Bob wrote does it just fine.
An "application" or "program", in contrast, is an automated or interactive bit of software that can be thought of as doing things "on its own", rather that work the user would do themselves.
Help Desk asked me to run the "Log Import" program, so it send them the relevant data.
The difference really is one of degree and issue, and there are lots of programs that do things the user could do themselves, and some scripts that do things users cannot do directly.
If you have the draw the line somewhere formally, draw it at "would your end-user do this manually if this thing wasn't here?"
- 6,371
As others have said, the answer isn't really clear cut. The way I see it, a script requires little to no user interaction once it is being run. Scripts are less flexible in that sense. An application or a program would be more robust, allowing for more user interaction while it is in the process of running. What you are writing seems like more of a program than a script to me, since it sounds like there will be quite a bit of user interface.
From my own experience, a script is something you would just provide some parameters to and run. It would be completely or nearly completely automated. On the other hand, if the user is continually being prompted, or having to provide input while the code is being run, that is a bit more robust and less automated. Scripts are more about automation vs. a program which is more robust with user interaction. As an example, a script can be something concatenating a list of txt files into one txt file. A program would would allow the user to continually choose files to concatenate during run time.
- 41
- 4
-
-
1From my own experience, a script is something you would just provide some parameters to and run. It would be completely or nearly completely automated. On the other hand, if the user is continually being prompted, or having to provide input while the code is being run, that is a bit more robust and less automated. Scripts are more about automation vs. a program which is more robust with user interaction. As an example, a script can be something concatenating a list of txt files into one txt file. A program would would allow the user to continually choose files to concatenate during run time. – DannyMac92 May 23 '14 at 17:30
There are no hard lines drawn in the sand for this. It often comes down to who is doing the work and how comfortable they are with non scripting languages and what level of rigor you have on scripts vs application. People writing scripts are generally not considered (generally) full blown developers that use source control, various design patterns, unit testing, etc. Scripts were generally created to avoid all that rigor and do a task fast. Developers will often still insist that scripts at least still be in source control but the places I've worked this rarely happens because generally it's not "developers" writing them and so control is minimal around them. It's people who want something done and know enough to be dangerous.
- 454
- 5
- 14