finally{}: Every Which Way But Loose

I recently saw yet another discussion online about PHP’s infamous naming convention exceptions and needle/haystack rotations. All the typical vitriol was there from the PHP haters, but I was very happy to see several new programmers add to the conversation or ask for clarifications and receive very supportive and educational responses from the thread. PHP is nothing if not consistent in its status as a recipient of the internet’s hatred. However, I am forever proud of our community’s ability to ignore the hate and still welcome and encourage newcomers.

But do the haters have a point about our inconsistencies?

I mean, they are not wrong that sometimes it is “needle/haystack” and other times it is “haystack/needle.” Sometimes it’s “in_,” and other times it’s “contains_.” I freely admit to needing to check the docs or use tooltips in an IDE when using functions I don’t use very often because I can’t remember which way it will go.

**Is it phpinfo() or php_info()? vardump() or var_dump()? Has anyone thought of just fixing this? ****

Most definitely. In fact, PHP RFC Consistent Function Names (consistent_function_names) will turn seven years old next month. This RFC proposes renaming any inconsistent functions and keeping their old names as aliases. No backward compatibility issues. Everyone can keep using whichever version they want to. It seems like a proposal that would satisfy the people who want everything renamed and those who do not want the names changed. So what’s its status? You guessed it. After all these years, it is still listed as “Under Discussion.”

Why is it so difficult to make a decision on something that garners PHP so much hate? Especially when there is seemingly a perfect solution to make everyone happy? **

Well, that’s the thing. Despite how it looks on the surface, renaming and aliasing is not a perfect solution. PHP has had these function names for so long they are expected to be a part of the code.

Does this mean we can’t change them because we don’t like change?

Absolutely not. It means is that other libraries and codebases have been working around those function names for well over a decade or two. For many codebases, it means they have wrapper functions using the proposed standardized versions of the function names because they prefer standardization. Or they have built custom functions and used the proposed standardized function names because those weren’t reserved. Standardizing the function names and order of variables means adding a lot of new reserved function names that could break a lot of code.

Don’t we add new functions to PHP all the time, which does the same thing?

True, but in those cases, the BC breaks come with the benefit of new functionality. In this case, we would be introducing a lot of BC breaks with no new functionality.

Isn’t a better dev experience worth it?

Maybe. Consider, though, the huge list of amazing new features, security patches, bug fixes, and everything else on the horizon for PHP. Do we really want to spend our limited core developer time on something that only improves the dev experience for some devs. It is really hard to justify this when it means losing time to work on a new feature or fix that could improve things for all devs. When dealing with limited volunteer resources, there are lots of tough decisions to make.

But what about all the haters who say PHP is ugly because of this?

As the saying goes, haters gonna hate. In PHP’s decades of life, there have always been haters. No matter what we do, there will still be haters. Look at the amazing modernization strides that PHP has made in the last five years! The perception that PHP is old, clunky, and ugly is not based on legitimate facts but rather long-held biases. Those biases aren’t going to go away even if we made naming conventions perfect, which I’d venture to say that no language could truly achieve given the ever-changing nature of programming.

So is this a dead issue?

Definitely not! There is merit to the concern and potential in the suggested solution. It just isn’t the right time for this kind of a change, and that’s why as we draw near to this RFC’s 7th birthday, this continues to be “Under Discussion.”

Related Reading
– PHP RFC: Consistent Function Names

Originally published in “Parallelize Your Code”, the February 2022 issue of php[architect] magazine.

finally{}: Experts or Out-of-touch?

After talking to someone about ideas for new security education, I popped over to check out the latest OWASP Top Ten list. A quote on their homepage stood out to me:

This category represents the scenario where the security community members are telling us this is important, even though it’s not illustrated in the data at this time.

The experts in their community were telling them that a specific issue was critical and widespread enough to warrant a place in the top ten, but the data they collected from codebases and users didn’t reflect this at all. Is this because the issue is too up-and-coming to be reflected in the current boots-on-the-ground numbers, but we need to act now because it will soon be a huge issue? Or is this a situation where the experts work on a level so different from the standard developer that the security risk is only applicable to them and not in everyday circumstances?

This difference got me thinking about how PHP has evolved over the last ten years. I used to closely follow PHP Internals and even got involved in a few of the discussions. I felt like it was important for me to be involved as much as I could. After all, these decisions were affecting my livelihood and my community. After about a year, I started feeling like I didn’t have much to contribute to the discussion. The people making the decisions worked in such a drastically different environment than me, and neither of us could truly relate to the other’s point of view. Not to mention, my point of view was not the exciting, academic, cutting edge side of things, so that didn’t help either.

I stopped making comments and just watched the discussions – keeping informed while lurking. Slowly, though, I faded further and further from the discussions until I found I was months behind on reading the posts and just unsubscribed. I felt a bit bad about giving up on being involved in internals, but I didn’t have anything to say about closures or scalar type hints or inheritance by anonymous classes. Honestly, most of the projects that I was working on were companies just starting to upgrade to 5.4. PHP 5.6 was still out of reach for many of my customers when 7 was being prepped for release. Many of my projects were short-term or light enough usage that a full-blown, properly abstracted system was unnecessary and would create a painful complexity without providing any needed benefits.

The thing I most needed the core internals team to do was to avoid any breaking changes so I could get my clients to upgrade. Needless to say, that was not their top priority, and rightfully so. I needed consistency to decrease costs for my customers. The core internals team needed to modernize the language and add features and constructs to match what other popular languages offer. I was concerned about ease of debugging while they were concerned about ensuring that PHP enforced strict standards to remove ambiguity in coding and encourage best practices.

Who was wrong? Who was out of touch? Was I too entrenched in old code and projects on a tight budget to realize the importance of these features which I couldn’t imagine ever using? Were the core devs too focused on academic theory and too isolated within huge corporate infrastructures to understand what devs like me needed?

The changes made to PHP from version 7 and beyond have skyrocketed the language into maturity, sped things up considerably, and helped PHP gain some of the professional respect it truly deserves. These are all great things. While they were streamlining things and enforcing best practices, they made things more difficult for developers like me who work with small businesses, ancient codebases, and hosting companies unwilling to upgrade. In making things more advanced to appeal to senior programmers and large organizations, they upped the difficulty for anyone trying to learn PHP or debug unfamiliar code.

There is always give and take, a bit of pain with each step forward. Change is hard. However, the beauty of our community is that we are so diverse. We have a strong group with people who push us forward and other people that keep us grounded. Thanks to this, PHP supports a vast range of organization sizes and project complexities. From small shops that just need a contact form to companies supplying content and services to millions of users, PHP is out there solving problems of all shapes and sizes. When we encounter differences, remember: we are experts in our own experiences, and because those experiences are so different, there’s a lot we can learn from each other.

Originally published in “Domain-Driven Resolutions”, the January 2022 issue of php[architect] magazine.

My New Adventure

As many of you know, I love working with PHP and being a part of its community. When I left php[architect], I chose not to jump into something new right away because I wanted to make really, really sure that whatever company I joined would not only embrace this love, but encourage it. I didn’t want to sell something; I wanted to build something to make the community a better place. Continue reading “My New Adventure”

Open Eyes

Here is my latest editorial for the May 2014 issue of php[architect] magazine:

php[architect] - May 2014Open Eyes

There are so many ways out there for us to make a difference in the lives of others. As technology pervades every aspect of life, our power as developers grows. We must use this power for good! Yeah, alright, I do a “good” job on projects. I make “good” decisions when it comes to security. I am “good” when I talk to non-technical users. That’s enough, right? Not even close. To truly be using your power for good, you must open your eyes to everyone around you, not just the loudest complainers or the most dangerous threats. You must be willing to put your words into action and work within the system that helps you stay employed (and fed). Continue reading “Open Eyes”