I was having a conversation with a peer, of mine, the other day. It was my assertion that PowerShell, at a minimum, blurs the line between programming and scripting. We then began to define what made a language a “programming” language. In most if not all cases, PowerShell seemed to be able to do those things. I would be interested in someone else’s opinion on what separates traditional programming languages from, specifically, PowerShell.
Thanks,
Jacob Sampson
Well, I’m not sure there was ever a line ;).
I think the “line” is more task-based. Are you “programming” an application that will be used by many people, support the business, and even implement main parts of the business? Or are you “scripting” to automate back-end administrative tasks?
PowerShell’s weaknesses in “programming” tend to come in around its lack of higher-end programmatic structures like classes, inheritance, strict scoping, and that kind of thing. v5 is a huge step in addressing the high end, actually.
Where PowerShell confuses people and blurs lines is that it’s fine if you want to hack out a quick maintenance script with it - or if you want to code up a class-based, heavily modularized, multi-file opus that presents user interfaces and manages an entire business process. It can do both. But it doesn’t directly compile (neither, really, does C#, if you think about it), and it doesn’t offer a lot of high-generation language features. It also - to date - isn’t accompanied by the sophisticated tooling that a developer is usually used to, although that’s starting to change.
If we wanted to make strict definitions, I would say “scripting” is a form of programming; all scripts are programs. Not all programs are scripts. Scripts tend to be procedural, beginning-to-end lines of commands. Literally, a script, like in a movie, that the computer performs. Other forms of programming may result in event-driven user interfaces that don’t run end-to-end. Scripts are common in systems administration because we’re usually using them to automate strict sequences of events. It’s still programming - just with a purpose that might be different from other uses of programming. Other approaches to programming might involve applications, which combine dozens of mini-scripts, along with event-driven triggers, to create interactive interfaces.
I understand your points and we came up with many of the same arguments. Our counters were, there are many “programming” languages that are not object based languages, there are many that don’t compile, and I have created full GUI based, event driven (clicking buttons and such) scripts that users use all throughout their day. In fact, I don’t know this for sure but, I can’t see why you couldn’t create a full blown QuickBooks style app. That being said I doubt I could use my PowerShell experience to get a traditional app-dev job.
Everything from “Hello, world” on up is technically programming. At a shell, I’d say that you cross that line as soon as you start to chain multiple commands together or produce some sort of logic.
That doesn’t mean you’re ready to go get a job as a software developer yet, but it’s the first step down that path. 
Many sysadmins are much farther along in terms of development knowledge / experience than a first-year CS student.
In my terminology, scripting means starting up programs in sequence/parallel in order to accomplish a given task. Programming means building logic and utilizing programming interfaces to accomplish a given task.
So if all your PowerShell script does is start up various .exe files with various parameters, then it’s a script. If you build your own tool from top to bottom and use APIs to accomplish tasks, then it’s a program. Same goes for Bash, Perl, Python, Java, C# and any other language you can name. They each have their strong suits, C#, Java and Python for example make scripting inconvenient, but excel at using APIs, where Bash is more of a scripting language. Perl and PowerShell are inbetweens that can do both, but they lack some of the strengths of real programming languages.
All good points. I admit to being biased, I am a real fan of PowerShell. Based on the comments above, I would say that, indeed, PowerShell does blur the line between traditional software development and traditional scripting. Not sure why that is important to me, probably because I think it adds some additional legitimacy to this product that I enjoy working with. I am anxious to look into the advances that version 4 and 5 will bring.
Jacob
A script automates clicking buttons and entering commands. A program creates buttons to click and commands to enter.
A programmer sits outside the system and prioritizes the optimization of what happens within the code at runtime. A scripter is part of the system, and is working to optimize the entire system.
Programmers work on the development team. Scripters work on the infrastructure team.
Scripters are cool. Programmers are so annoying.
Tim C
(Though I do both activities, guess which label I use : )
Forgot the big one.
Scripters are lazy.
Tim C
(I’m not lazy; I’m optimizing my resources.)
To quote Jeffrey Snover in the Monad Manifesto…
“John Ousterhout described the distinction between scripting and systems programming well in his paper Scripting: Higher Level Programming for the 21st Century. Ousterhout posits that scripting allows for “gluing” applications together – a higher level abstraction than system programming – enabling (even) more rapid application development than today’s systems programming languages.”
Great quote, although PowerShell seems to break that definition of scripting, or at least has the ability to. Now, if only scripters could make application development money.
In response to another one of your posts, namely this statement, “… A script automates clicking buttons and entering commands. A program creates buttons to click and commands to enter.” PowerShell seems to fit the definition of a program. Through the .net framework (same as many languages that take advantage of .net) I can create buttons to click and commands to enter."
Thanks,
Jacob Sampson
I’d adopted the thought of a scripting language as being defined by something that was executed immediately, line by line, natively from within a console.
Until someone very quickly broke the spell by then asking what vbscript was…