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.

One of the key strengths of any community is its diversity.  I don’t mean in the usual race-and-gender kind of diversity (although that’s important too), but more broadly.  Any given person only has so much experience to draw from, and only one (or maybe a very few) perspectives to bring to any given problem or situation.  Two people with the same experience may add (almost) twice as much available labor, but add only a little bit of problem solving ability.  Two people with different backgrounds and experience can double, or more than double, the problem solving ability.

Working with PHP, there are people of all sorts of professional backgrounds.  There are people that have only been out of college for a few years; there are people who have been coding long enough to have the proverbial (or literal) gray beards; there are people who didn’t go to college.  I’ve worked with CS majors, English majors, Physics PhDs, business majors, art majors, college drop outs, and culinary school graduates.  I’ve met people who are freelancers, agency consultants, product developers, hobbyists, and in-house “computer person”.

It’s that breadth of experience that is our secret weapon.

I’ve been part of the Drupal community for over a decade now.  The Drupal community is vast.  When I first started coming to PHP events, what struck me most was how quaint they were compared to what I was used to.  Most of the PHP conferences in the US cap out around 200 people.  That’s a small DrupalCamp.  DrupalCons in Europe generally pull around 2000 people; in the US, 3000.  Many people I talk to at PHP events are in absolute shock to hear that, and when they come to DrupalCon get a deer-in-headlights look about them.  How can there be so many Drupal developers?

Well, there aren’t.  I mean there are tens of thousands of Drupal developers around the world, on every continent, and that’s just the ones we know about that are actively engaged in the community.  But only half, half of DrupalCon Europe attendees describe themselves as back-end PHP developers.  Maybe a third of DrupalCon US attendees do.  So who are the rest of them?

They’re designers.  They’re front-end developers.  They’re UX experts.  They’re business owners.  They’re content strategists.  They’re project managers.  All interested in some way in building Drupal or building something with Drupal.  Although Drupal has often been accused of being “by dev geeks for dev geeks”, nothing could be further from the truth.

It’s that breadth of experience that is our secret weapon.

Teams that are diverse along many axes (both the obvious ones and not so obvious) succeed because they can, collectively, look at a problem from many different angles at once.  And by being part of such a team, you can learn, both deliberately and by simple osmosis, how to look at a problem from more than one angle.

That’s the benefit of a diverse community.  It is a loose team from which you can learn and experience different perspectives.  By engaging with different people and learning from their experience and perspectives, you borrow some of their power, and they borrow some of yours.

Most importantly, though, they can help you get more diverse experience yourself.  Not all the world is Drupal, or Symfony, or Zend, or Laravel, or WordPress.  By getting your own experience with a more diverse set of tools, your brain changes to be able to think about a problem in different ways.  Not just in a Drupal way, or Symfony way, or Zend way, or Laravel way, or WordPress way, but in many or all of those ways, through both your own experiences and the shared experience of others.  You can look at a problem and ask “how would Drupal do this? How would Laravel do this?  How would Symfony do this?”  Then combine them all in various ways to find a solution.

It’s that breadth of experience that is your secret weapon.

Getting out of your bubble and sharing experiences with others is what a healthy community lets you do.  And that, in turn, gives you a broader perspective to bring to the table.  Quite simply, diverse community experience makes you smarter.

And it’s not just a developer thing, either.  I’ve been involved in many different communities in my time.  Only some of them have been developer related, yet all of them, over time and with exposure, have helped to rewrite my brain.  All of them have had people to learn from.  In some ways, the subtle influences that seem to have nothing to do with development can be the most important, because they’re subconscious.  You may not think of involvement in a sci-fi club, or a religious organization, or a dance community, or a sports community as having much impact on your software development, but it does, because every healthy community you’re part of has something to teach you, and you have something to teach them.

It’s that breadth of community experience that is your secret weapon.

The caveat, of course, is that I refer to “healthy communities”.  Sadly, not all communities are healthy.  Unhealthy communities demand closed-minded thinking.  They deny experiences, rather than offer them.  They encourage people to stay “on the island” rather than gathering knowledge to share from many sources.  Unhealthy communities refuse to accept the benefits that a diverse background can offer.

Fortunately, PHP is not such a community.  The PHP community is broad and healthy.  The PHP community has reinvented itself in the past half-decade to be more eclectic and mixed and diverse.  Could it go further?  Certainly, but it has come a long way, with people from a variety of different backgrounds, perspectives, and experiences able to meet, share, learn, help, build, and teach.  And most importantly, to encourage its members to meet, share learn, help, build, and teach.  Because the more varied experiences we can share, the stronger we all are.

And that’s why the PHP community needs you.  Because you have a background, experience, and perspective that we want to learn from.  You can learn from us, and we can learn from you, because that is what a healthy community does.  You are our next secret weapon.

It’s the breadth and depth of the PHP community that is your secret weapon.

And it’s the breadth and depth, and generosity, of the community that is PHP’s secret weapon.