Things That Matter Most

Things That Matter Most

Scripting vs Programming: PHP and OOP

by

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.

Making Singletons Safe in PHP

by

Last time, I argued in favor of the Singleton pattern in WordPress.  Singletons make sense in WordPress specifically for several reasons:

  • They live in the global scope without using the already abused/overused global keyword
  • As a distributed application maintained by several hundred developers, they prevent problems that likely arise from others misusing your code

But one of the goals of object-oriented software development is to make your code reusable.  The Singleton pattern as I explained it last time isn’t really applicable outside of WordPress.  Typically, Singletons are a really bad idea.  But rather than get hung up on the term and settle for the knee-jerk “it’s bad, don’t use it” conclusion, let’s take a deeper look.  There’s a reason Singletons exist; they solve a specific problem.  So rather than reject them out of hand, let’s make a minor change to make them safe for general PHP use.

There were two major arguments against Singletons throughout the comments, Twitter posts, Y Combinator thread, and private emails that followed my last post. First, that Singletons introduce hidden dependencies in your code.  Second, that Singletons are nearly impossible to unit test.  Both of these arguments are valid, but I have counters to each. [Read more…]