With the release of the much-anticipated PHP 7.4 and the planned release of PHP 8.0 next year, there’s been discussion in some quarters of whether or not PHP is getting “too strict”. Some have even phrased it as an existential split between two fundamentally different views of the language, incompatible worldviews on strictness vs flexibility that are at odds and will tear the language apart bit by bit if nothing is done to address that schism.

I do not share that view. Quite the contrary, I find PHP’s balance in recent years between casual code style and more formal code style to be one of its most remarkable and strongest features, and one we should be both proud of and continue to encourage.

It’s true there really are different ways and styles to approach programming; not all of them are always valid, but most are valid in certain situations and contexts. When writing a one-off simple script, or a hit counter, or some other “casual” use case where the code base is small, it’s entirely true that a lot of the formalisms and stricter, more pedantic language features are unnecessary and can in some cases, get in the way.

On the other hand, the larger and more complex your application, the more that formalism and strictness can save your butt. Rather than get in your way, it heads off bugs and design flaws early, before they can fester and become even more expensive to fix. I wouldn’t care if a simple side project app isn’t strictly typed all the way through; I wouldn’t trust an ecommerce application that isn’t.

But that’s the great thing about PHP: We can do both. While I encourage all developers to leverage PHP’s opt-in strictness and typing and other formal design tools as much as possible, they’re not required. If your use case really doesn’t call for them… don’t use them. If it does, use them.

Where some languages are engineered for big systems and thus have a high ramp-up to learn all the moving parts, and others are engineered for casual use cases and thus struggle to be scalable to large and complex use cases, PHP allows a “pretty good” of both worlds. It’s easily approachable, easy to learn, but contains an increasing number of features to allow for a more robust and self-checking programming style.

We can (and frequently do) debate when using those stricter, more explicit features is appropriate; personally I prefer to use them even on tiny projects as it’s good practice, but not everyone does, and that’s OK. But the fact that PHP lets you gradually scale from untyped loosey-goosey code to partially typed to strictly typed code, with casual error handling to strict error handling, all in the same language, all in an inter-compatible way, is absolutely incredible and something the PHP core team should be proud of.

I’m all for adding more robust formal tools to the language; I’m excited about typed properties and short lambdas in PHP 7.4; I am looking forward to union types in PHP 8, and I’d be ecstatic if we could figure out how to wrap intersection types and generics into the mix. There’s plenty of other language tools to help constrain large code bases and algorithms we could consider, too. But by necessity all of those would be opt-in features, just like types are now; and that’s what’s great about them, and about PHP.

I’ve never agreed with the argument that type definitions or classes make the language inherently harder to learn, but PHP, fairly unique among languages I know, lets you learn them piece by piece or all at once at whatever your pace happens to be. That wasn’t a conscious, deliberate decision, but it’s how the language has evolved and we are all better off for it.

We don’t need to split up PHP. We don’t need divergent “modes” or “editions”. We need to continue doing what PHP has been so remarkably good at: building a language that scales with you, from casual loosey-goosey scripts to formally typed and structured and error checked designs that would make a Computer Science professor proud. Fitting all of those into one language is hard, but PHP has done it, and we should continue to do it.

And that’s something we can all be thankful for.