| « The hidden costs of bad code | The Cardinal Sin Of Object Inheritance » |
I read a very dissapointing post by Anthony Ferrara called Rambling on Internals last week. It describes how frustrated Anthony has become with PHP’s internals mailing list, the process that PHP uses to select and create new features, and the plain fact that there are many trolls on the PHP internals list who have their own agendas, not the agenda of the PHP project, at heart.
Reading Anthony’s article was an eye-opening experience to the challenges that PHP faces. And while I can’t say that I agree with all of his statements or choices, I can say with some certainty that I understand his point of view. PHP Internals has long been known as a troll’s paradise.
And then, just today, there was this discussion.
The speed at which the discussion degenerated into a shit slinging contest was stunning. Truly.
The truth is that every open source project has challenges, trolls, people who have their own agendas and individuals who aren’t interested in adopting new ideas. And every project has to figure out a way to solve these issues, in order to move forward.
PHP is the world’s most widely spread language, available on almost every single web server you can buy from a third party. And yet, despite PHP’s success, instead of focusing on improving the innovation and usefulness of the language, it seems people are more than content to celebrate its successes and assume we’re done making things better.
Great ideas like named arguments, function autoloading and others fall by the wayside as “invented problems” or “unnecessary additions.” PHP 5.5 has just been released with the smallest user-facing feature set I’ve ever seen from PHP; sure the “yield” keyword is useful, and the opcache was a tremendous amount of work. But where are the improvements to the object model? Where are the new libraries that made it into core? What have y’all been doing for a year?
Oh, right, you’ve been fighting over silly things like whether or not named arguments and scalar type hinting are invented problems or not.
I don’t know how to write C code, and even if I learned I’m pretty sure that the PHP code base would suck my soul dry. I rely upon the people who work on internals to do great things so that I can do great things, too. If internals descends into chaos and sheds good developers like Anthony, then we all stand to lose. PHP will slowly decay into a second-rate language, and our dominance over the web? It will end.
PHP’s cause of death will be us. We can’t let this happen.
Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP
Posted on 9/11/2013 at 12:19 pm
Bradley Holt (@BradleyHolt) wrote at 9/11/2013 12:27 pm:
What if PHP were written in PHP? Would we see more every-day PHP developers becoming core contributors? This would likely take a monumental effort, but it’s an interesting idea to think about. There’s no reason that I can think of as to why this isn’t technically possible. The gcc C compiler is written in C. Why couldn’t PHP be written in PHP?
Brandon Savage (@brandonsavage) wrote at 9/11/2013 12:53 pm:
Anthony Ferrara did that, he wrote PHPPHP. Great prototyping language.
Claude Adrian (@CodeAngry) wrote at 9/11/2013 1:24 pm:
I think this is the doom of Open Source languages built by communities, they become complacent. If they were actually making money from it, it would have been a huge difference. Like charge all hosting companies a small amount or something per server.
I’ve seen many Open Source projects fade into oblivion as people need to eat and pay bills too. It’s fun for a while but reality kicks in. For such a language you’d need full time devs working only on this and not worrying about anything at all. And just thinking of how wide-spread PHP is, it should be very easy.
I don’t know how PHP devs make money but… if they did make enough of them, they should add features like there’s no tomorrow. I would if I was behind a scripting language.
Maybe I’m completely wrong but that’s how I see it.
And there’s many features required. Like optional static typing, friend functionality, auto-loading functions/namespaces, __to… like __toArray(), easier getters/setters and such. Loads of them.
PS: As to PHP written in PHP, that’s a very bad joke. Any scripting language is by default 5-15 times slower than native code, at least. Now do that twice… PHP is already a scripting language, why pull an Inception on it?
@Claude Adrian: Obviously I’m talking about compiling the PHP language down to C++ (or directly to assembly), not having the language itself interpreted at run time. So, there would be no performance implication to this. As to why, I already said: the goal would be to make contributing to the core of PHP easier for every-day PHP developers.
Evert Pot (@evertp) wrote at 9/11/2013 2:48 pm:
Claude.. incorrect assumptions, see PyPy as an example:
http://stackoverflow.com/questions/2591879/pypy-how-can-it-possibly-beat-cpython
I imagine this is a lot harder with PHP though.
I also disagree with your notion that “adding features like there’s no tomorrow” is a good thing. Different people have different priorities. I have some ‘nice to haves’ myself, and some other features that I would hate to see in PHP. Many people will share that, but put different features in those two categories.
I rather see a BDFL.
@BradleyHolt: FB has/had something like that. But if I wanted to compile PHP into binary, I’d rather use something else. Like .NET or other higher level languages than C++ and lower than PHP. I also write native C++ so I would personally go directly for C++ and implement my own web server that fits the model of the project it’s supposed to run. Nevertheless, it’s not that easy.
@EvertPot: The more features you have, the more happy users you’ll have. It’s easy. And as long as you manage to maintain a good backward compatibility… new features are good! Nobody can convince me otherwise.
Pablo Godel (@pgodel) wrote at 9/11/2013 8:26 pm:
Something that has to be seriously considered is to create a foundation that manages the future of PHP.
Yes, we have The PHP Group, but what is this? A foundation like The Apache Foundation, where individual sand companies belong and contribute to keep the language moving forward, help employ as many core developers as possible, etc. This may be the only way to keep the PHP language alive.
Pierre (@pierrejoye) wrote at 9/12/2013 4:32 pm:
“PHP 5.5 has just been released with the smallest user-facing feature set I’ve ever seen from PHP”
Well, it is hard to have faster, better, more stable releases with releases like what we used to do (like 5.3 f.e.).
Smaller releases but more frequent is easier to manage, to stabilize and to release in time. It is also easier to migrate apps.
“What have y’all been doing for a year?
Oh, right, you’ve been fighting over silly things like whether or not named arguments and scalar type hinting are invented problems or not.”
Wow. Now you felt down in the trolling hole.
As I agree on so many points pointed out by many people about how hard it is to contribute to PHP. I have been trying to improve that since long (with quite some success, despite the recent discussions about how bad we are).
But I can’t and never will let every core developer get bashed and shoot down because of one or two of them. I can’t and I won’t.
Also I feel like our worst enemy are traffic/marketing driven “discussions”. It does not help anyone but the author of a post.
It is time to stop bashing, both sides and get things done, from a respectful point of view. We have the tools to avoid bad or unilateral decisions (RFCs and voting process), which are a *huge* progress, if you compare to what we have been done in the last decade.
About keeping PHP alive, I am not sure what you (post and comments) meant. PHP is alive, but it has a very bad behavior problem, and not only in the core. This is something we must solve, the sooner the better. Injecting new blood, creating a balance between old school and new ones may work very well (did so far, 5.4/5 are perfect examples of that).
my 2cent :)
Larry Garfield (@Crell) wrote at 9/18/2013 1:37 am:
Pierre, if the problem is a small minority of PHP devs, what’s to be done about it?
It’s a well-known phenomenon that a small minority can corrupt and destroy a healthy community. “All that is required for evil to triumph is for good people to do nothing.”
“But I can’t and never will let every core developer get bashed and shoot down because of one or two of them. I can’t and I won’t.”
A noble position, and one I applaud. So what’s to be done about those one or two that give the other 30 a bad name and drive off good contributors?
I’ve never seen Internals collectively say “you’re no longer welcome” to someone for being an asshole. Where’s the pushback for insulting arrogance like http://marc.info/?l=php-internals&m=137897407705466&w=2 ?
Internals needs a way to police itself and enforce codes of conduct, or else “one or two” people *will* get “every core developer get bashed”. And if they can’t do something about poisonous people or poisonous situations, then it will be justified bashing.
| « The hidden costs of bad code | The Cardinal Sin Of Object Inheritance » |