When I started my professional career as a developer, I dabbled in several programming languages. I built software in Visual Basic, C#, PHP, Ruby, Python, JavaScript. I hadn’t settled down on one particular language, and it made getting help a bit difficult.
What as the most confusing was how different professionals categorized each language. Some were “programming languages.” Others were “scripting languages.” I didn’t have any idea what that meant; it felt incredibly arbitrary and was often a distinction used in a condescending manner.
Now, with a few years of experience under my belt, I’m comfortable explaining the difference.
Scripting
A scripting language is one used, typically server-side, to script the behavior that handles a request. A client makes a request though their browser or application, the server parses that request and passes it to a script, the script generates a response and passes it back to the client through the server.
When you make a request to WordPress, you’re using PHP as a script. When you make a request to a Django app, you’re using Python as a script. When you make a request to a Rails app, you’re using Ruby as a script.
You’re not using a long-lived program, you’re using a script.
Programming
Conversely, a programming language is used to build a long-running application. A single instance that handles multiple requests. Visual Basic, C#, and C++, for example, are all compiled programming languages that, when compiled, produce a binary application. These applications can be instantiated on a server (or client) and run indefinitely, handling requests as they come in and producing the appropriate response.
Similarly, JavaScript is an interpreted programming language that runs through a just-in-time compiler to produce a compiled, long-running, in-browser application that can listen for and process multiple requests from the browser. This long-running, event-driven nature of JavaScript makes it a great candidate for server-side programming as well thanks to Node.
In any case, JavaScript and its compiled relatives are programming languages, not mere scripts.
The Consequences
Talking about object-oriented programming in PHP is all the rage right now. Conferences feature numerous presentations on “OOP best practices,” the number of PHP books about object outnumber those in other languages on the shelves at Barnes and Noble, and most technical blogs are covering different object-related design patterns and tips.
OOP doesn’t make much sense when we’re talking about a scripting language, though.
Because PHP is a scripting language, your carefully-constructed objects only live for a single request. Debating Singleton patterns in a world where your object is only ever instantiated once during a request is bikeshedding. Learning proper object lifecycle management – I’ve only seen a developer use a proper destructor once – isn’t really necessary when the script flushes everything down the drain at the end of the request.
The consequence of using a scripting language to power the web is that we spend too much time trying to shoe-horn object-oriented programming concepts into a place where they don’t really make a different in the way of performance.
That said, the patterns we use when building an OOP application do help for better code organization and readability. We just need to be very careful when heralding OOP as “the only way” in a scripting world, as it’s not. It’s not even the most necessary metric against which we judge our PHP applications.