6 ms·

PHP: Cracks in the foundation

134 points by chrismsnz 15y ago

cobychapple 15y ago
Learning PHP is how I got into web programming, and for that I'll be eternally grateful. Since starting to explore languages like Ruby and Python however, I've been reluctant to use PHP in situations where others are an option, so I'm really glad to hear things are picking up in PHP's development—it can only mean good things for the development community.
MrEnigma 15y ago
This list seems a bit tired. There are a couple of things in here that are actual issues, but they seem small in scope, and easy to work around. As for the is_a changes, I think it's probably for the better, as they say, you have to break some eggs to make an omlette. Also, the article first complains about not having Unit Tests to catch this, and then later complains about it being ignored on release. Ultimately unit tests are great for refactoring, but when code is actually being changed, some sort of process needs to be followed for that (dictatorship, consensus building, anarchy?) I program in PHP, and we don't depend on too many outside libraries. And for cases where we do, we will simply fix these issues. It used to be that upgrading PHP was much 'easier' to do, meaning you'd just go out and do it, and would hardly breaking anything (at least in my experience). However lately it seems that the risk is higher. However I welcome this, because it means the language is progressing and we're getting a lot of additional things. For all the projects I've worked on, we make sure the code works with that version of PHP. Unit/integration/regression/selenium/using it on development for awhile/whatever are all valid things to do, if you have issues you fix them and move on. 5.3 was great, excited for 5.4 with traits as well. It's a great time to be writing PHP.
- MrEnigma 15y ago
  The array/sorting things are sometimes just things developers will have to deal with until someone makes new methods and deprecates the old ones. I used to think that the code base needed to be perfect, no extra cruft, only code that's necessary, switch parameter order just to make things match. However in doing so it adds a tremendous amount of pain and risk. My OCD does't want to handle it, and it's always good to strive to get to that point, but ultimately nothing is perfect, so might as well deal.
zzzeek 15y ago
> PHP, being a language intended for beginners, I've never heard this before. PHP is certainly very easily picked up by beginners, and in my own opinion makes it easy for said beginners to spend years and years not moving very far beyond beginner-level architectural patterns (just look at the source of Wordpress for an example), but do the creators of PHP really consider it to be "a language for beginners" ? I have an entirely selfish agenda here. The next time some know-nothing manager promises his client "we have the top programmers with years of experience who will write the highest quality code you can get", then demands that we do everything in PHP because that's all he knows, we can say, "really? You're going to charge the client all that money, then give the client an app written in a "beginner" programming language ?"
- mechanical_fish 15y ago
  All else being equal (i.e. assuming equal functionality and performance), customers would prefer code that's written in "beginner" programming languages. Customers don't always know many things about code, but every single one of them knows how to count money, and they fantasize about replacing their maintenance staff with a bunch of beginners. Hiring competent beginners is difficult enough. An important aspect of this problem: Even if the overall system is too complicated for beginners to understand, beginners may be able to usefully tinker with the system if it is built out of parts that they understand. The problem with PHP-based systems is that their most complicated parts may need to be built out of PHP, but the bonus is that all their simple parts are also built out of PHP, and often the bulk of the maintenance boils down to tinkering with the simple parts.
  - dhx 15y ago
    This is very important. Code that is simple is easy to maintain. This is not to say that simplicity wins over the use of complex design patterns and abstractions in every scenario. It's a trade-off that needs to be considered on a case-by-case basis. This is especially true in the open source arena where it is critical that new developers can come along and read, understand and improve existing code. Code that is too complex will not be understood and will almost certainly lead to errors.
paulhauggis 15y ago
PHP has already proven itself time and time again. There are lots of high-traffic websites running PHP successfully. Yes, it's easy to make a simple script and get it running fast, but you can also engineer complex OO applications. One of the reasons I've stayed away from things like rails is because it puts too many layers on top of things like the database. I've known a few developers that use Django or Rails and have no idea how things work underneath. This is a disadvantage. Especially if you need to do something like optimize a database query and to do so, you have to actually change the framework that maps SQL to an object.
- andrewvc 15y ago
  I've known a few developers that use Django or Rails and have no idea how things work underneath. This is a disadvantage. Seriously, that's not even an argument, it's an anecdote of dubious validity. My personal experience as a rails developer has been that most of the people I've worked with know SQL quite well, and are fully capable of writing straight SQL when required. Really though, I'm only offering a counter-point. If you truly want to make the case that NOT_YOUR_FRAMEWORK_DEVELOPERS are ignorant, please prove it statistically or find a forum other than hacker news to flame on.
  - paulhauggis 15y ago
    "Seriously, that's not even an argument, it's an anecdote of dubious validity." I don't have to prove anything. This is why I started it out with "I've know a few developers". "NOT_YOUR_FRAMEWORK_DEVELOPERS are ignorant, please prove it statistically or find a forum other than hacker news to flame on." You are one of the problems with hacker news right now. I was merely stating my opinion. Nowhere did I say "all developers". Just because my opinions is different than yours doesn't mean I am trolling or flaming. Also, when assembly went out of style and c became popular, less and less developers knew how things worked at a lower level. It makes sense that the same thing will happen with frameworks and libraries that are at a higher level.
    - dasil003 15y ago
necro 15y ago
I was at conference recently talking to a group of "developers" and one finally asked, so what kind of language requirements do you have of the people you hire. I answered that I don't really have any requirements of the specific language. They all looked at each other and nodded, oh, so you must not be too advanced as you are not looking for people with experience in new advanced languages. I was a little surprised because I was thinking the EXACT opposite. I work with _developers_. I don't really give a shit what syntax they prefer of are used to. If you can create your own framework error handling, message queues, custom db libs, etc then that is useful. A real dev can pick up a new language and syntax in a week, so just because you can write hello world in 10 languages or use some rails ORM to output some stuff does not make you a developer. It's all starting to take me back to my youth watching Robotech and remembering the Zentradi, an advanced race with awesome technology and tools that were developed for them generations ago, but none of the understood how any of it worked or how to fix it, they could only use it. If it broke, they just start over with a new copy instead of debugging it. I hope that the our new generation wont end up like that. I recently interviewed a recent CS grad that had no idea of the correlation of array of characters and pointers to those characters. You know that it's all just addresses to memory, right? Anyway, of course there are those who truly dissect and get all the languages and their benefits but are few and between. Give me a dev that "gets it" in one language any day, instead of someone who thinks remembering the function call or some syntax in 10 languages is of value. If I hire someone here is how I rank them... 1. 5 years experience in C 2. 5 years experience in PHP 3. 5 years experience in Rails 4. 5 years experience in Rails, Python, erlang, java, php, c, other languages dujour. Ok, there are people that are just picking up PHP and don't know squat, but at least they know they are beginners and are teachable.
- dhx 15y ago
  You don't need 5 years of experience in any single language to have a solid understanding of the fundamentals of computing and programming. I'd rather hire someone that can give you an approximate assembly of a C function (as executed by a CPU), understand how XML documents are stored in memory for efficient querying and parsing, know how to avoid cross-domain browser security problems, have an understanding of multithreading (locks, semaphores, race conditions, etc) and an application of recursion in some other language. I wouldn't care what the knowledge is, as long as it is well rounded and demonstrates that the candidate is capable of pulling apart complex systems to gain a deep understanding in a short period of time. The ability to reason (with passion and authority) about which language or pattern is best suited to a given scenario is also vital. Time is a terrible measure, partly because it fails to recognise that 5 years of bad/shallow/incorrect experience is worse than 2 weeks of gaining a deep understanding of a new language/pattern.
grandinj 15y ago
But it can be fixed. Rather than specify a grammer in BISON and generating C code, write your parser as a recursive descent parser. Then add some annotations and auto-generate grammar files from the C code. This is the same principle as generating document using DOXYGEN, the closer the annotation is to the code, the more chance there is of the annotation being correct. Also, its something you can incrementally.
seanchambers 15y ago
I havent developed in php in years, but here is my tale on it from my current point of view. Of this whole article the one thing that jumped out at me was "broken and ignored tests". Being an open source developer myself, I greatly value the tests in every open source project. Nevermind the fact that this is PHP which warrants the use of tests even further because of the various points the author makes. I hope that going forward the maintainers of the PHP core ensure that every bug fix has a passing unit test along with it. That would at least keep the dam holding back the flood intact.
- justincormack 15y ago
  Adding tests for bug fixes doesnt necessarily help when your code is in that state. I think you are better off looking for coverage on tests, and trying to write specs eg formalize the parser as mentioned. Probably a lot of tests now are from previous bugs, but the code has drifted and they have not been maintained.

134 points by chrismsnz 15y ago

Learning PHP is how I got into web programming, and for that I'll be eternally grateful. Since starting to explore languages like Ruby and Python however, I've been reluctant to use PHP in situations where others are an option, so I'm really glad to hear things are picking up in PHP's development—it can only mean good things for the development community.

MrEnigma 15y ago

This list seems a bit tired. There are a couple of things in here that are actual issues, but they seem small in scope, and easy to work around. As for the is_a changes, I think it's probably for the better, as they say, you have to break some eggs to make an omlette. Also, the article first complains about not having Unit Tests to catch this, and then later complains about it being ignored on release. Ultimately unit tests are great for refactoring, but when code is actually being changed, some sort of process needs to be followed for that (dictatorship, consensus building, anarchy?) I program in PHP, and we don't depend on too many outside libraries. And for cases where we do, we will simply fix these issues. It used to be that upgrading PHP was much 'easier' to do, meaning you'd just go out and do it, and would hardly breaking anything (at least in my experience). However lately it seems that the risk is higher. However I welcome this, because it means the language is progressing and we're getting a lot of additional things. For all the projects I've worked on, we make sure the code works with that version of PHP. Unit/integration/regression/selenium/using it on development for awhile/whatever are all valid things to do, if you have issues you fix them and move on. 5.3 was great, excited for 5.4 with traits as well. It's a great time to be writing PHP.

MrEnigma 15y ago
The array/sorting things are sometimes just things developers will have to deal with until someone makes new methods and deprecates the old ones. I used to think that the code base needed to be perfect, no extra cruft, only code that's necessary, switch parameter order just to make things match. However in doing so it adds a tremendous amount of pain and risk. My OCD does't want to handle it, and it's always good to strive to get to that point, but ultimately nothing is perfect, so might as well deal.

zzzeek 15y ago

> PHP, being a language intended for beginners, I've never heard this before. PHP is certainly very easily picked up by beginners, and in my own opinion makes it easy for said beginners to spend years and years not moving very far beyond beginner-level architectural patterns (just look at the source of Wordpress for an example), but do the creators of PHP really consider it to be "a language for beginners" ? I have an entirely selfish agenda here. The next time some know-nothing manager promises his client "we have the top programmers with years of experience who will write the highest quality code you can get", then demands that we do everything in PHP because that's all he knows, we can say, "really? You're going to charge the client all that money, then give the client an app written in a "beginner" programming language ?"

mechanical_fish 15y ago
All else being equal (i.e. assuming equal functionality and performance), customers would prefer code that's written in "beginner" programming languages. Customers don't always know many things about code, but every single one of them knows how to count money, and they fantasize about replacing their maintenance staff with a bunch of beginners. Hiring competent beginners is difficult enough. An important aspect of this problem: Even if the overall system is too complicated for beginners to understand, beginners may be able to usefully tinker with the system if it is built out of parts that they understand. The problem with PHP-based systems is that their most complicated parts may need to be built out of PHP, but the bonus is that all their simple parts are also built out of PHP, and often the bulk of the maintenance boils down to tinkering with the simple parts.
- dhx 15y ago
  This is very important. Code that is simple is easy to maintain. This is not to say that simplicity wins over the use of complex design patterns and abstractions in every scenario. It's a trade-off that needs to be considered on a case-by-case basis. This is especially true in the open source arena where it is critical that new developers can come along and read, understand and improve existing code. Code that is too complex will not be understood and will almost certainly lead to errors.

paulhauggis 15y ago

PHP has already proven itself time and time again. There are lots of high-traffic websites running PHP successfully. Yes, it's easy to make a simple script and get it running fast, but you can also engineer complex OO applications. One of the reasons I've stayed away from things like rails is because it puts too many layers on top of things like the database. I've known a few developers that use Django or Rails and have no idea how things work underneath. This is a disadvantage. Especially if you need to do something like optimize a database query and to do so, you have to actually change the framework that maps SQL to an object.

andrewvc 15y ago
I've known a few developers that use Django or Rails and have no idea how things work underneath. This is a disadvantage. Seriously, that's not even an argument, it's an anecdote of dubious validity. My personal experience as a rails developer has been that most of the people I've worked with know SQL quite well, and are fully capable of writing straight SQL when required. Really though, I'm only offering a counter-point. If you truly want to make the case that NOT_YOUR_FRAMEWORK_DEVELOPERS are ignorant, please prove it statistically or find a forum other than hacker news to flame on.
- paulhauggis 15y ago
  "Seriously, that's not even an argument, it's an anecdote of dubious validity." I don't have to prove anything. This is why I started it out with "I've know a few developers". "NOT_YOUR_FRAMEWORK_DEVELOPERS are ignorant, please prove it statistically or find a forum other than hacker news to flame on." You are one of the problems with hacker news right now. I was merely stating my opinion. Nowhere did I say "all developers". Just because my opinions is different than yours doesn't mean I am trolling or flaming. Also, when assembly went out of style and c became popular, less and less developers knew how things worked at a lower level. It makes sense that the same thing will happen with frameworks and libraries that are at a higher level.
  - dasil003 15y ago

necro 15y ago

I was at conference recently talking to a group of "developers" and one finally asked, so what kind of language requirements do you have of the people you hire. I answered that I don't really have any requirements of the specific language. They all looked at each other and nodded, oh, so you must not be too advanced as you are not looking for people with experience in new advanced languages. I was a little surprised because I was thinking the EXACT opposite. I work with _developers_. I don't really give a shit what syntax they prefer of are used to. If you can create your own framework error handling, message queues, custom db libs, etc then that is useful. A real dev can pick up a new language and syntax in a week, so just because you can write hello world in 10 languages or use some rails ORM to output some stuff does not make you a developer. It's all starting to take me back to my youth watching Robotech and remembering the Zentradi, an advanced race with awesome technology and tools that were developed for them generations ago, but none of the understood how any of it worked or how to fix it, they could only use it. If it broke, they just start over with a new copy instead of debugging it. I hope that the our new generation wont end up like that. I recently interviewed a recent CS grad that had no idea of the correlation of array of characters and pointers to those characters. You know that it's all just addresses to memory, right? Anyway, of course there are those who truly dissect and get all the languages and their benefits but are few and between. Give me a dev that "gets it" in one language any day, instead of someone who thinks remembering the function call or some syntax in 10 languages is of value. If I hire someone here is how I rank them... 1. 5 years experience in C 2. 5 years experience in PHP 3. 5 years experience in Rails 4. 5 years experience in Rails, Python, erlang, java, php, c, other languages dujour. Ok, there are people that are just picking up PHP and don't know squat, but at least they know they are beginners and are teachable.

dhx 15y ago
You don't need 5 years of experience in any single language to have a solid understanding of the fundamentals of computing and programming. I'd rather hire someone that can give you an approximate assembly of a C function (as executed by a CPU), understand how XML documents are stored in memory for efficient querying and parsing, know how to avoid cross-domain browser security problems, have an understanding of multithreading (locks, semaphores, race conditions, etc) and an application of recursion in some other language. I wouldn't care what the knowledge is, as long as it is well rounded and demonstrates that the candidate is capable of pulling apart complex systems to gain a deep understanding in a short period of time. The ability to reason (with passion and authority) about which language or pattern is best suited to a given scenario is also vital. Time is a terrible measure, partly because it fails to recognise that 5 years of bad/shallow/incorrect experience is worse than 2 weeks of gaining a deep understanding of a new language/pattern.

grandinj 15y ago

But it can be fixed. Rather than specify a grammer in BISON and generating C code, write your parser as a recursive descent parser. Then add some annotations and auto-generate grammar files from the C code. This is the same principle as generating document using DOXYGEN, the closer the annotation is to the code, the more chance there is of the annotation being correct. Also, its something you can incrementally.

seanchambers 15y ago

I havent developed in php in years, but here is my tale on it from my current point of view. Of this whole article the one thing that jumped out at me was "broken and ignored tests". Being an open source developer myself, I greatly value the tests in every open source project. Nevermind the fact that this is PHP which warrants the use of tests even further because of the various points the author makes. I hope that going forward the maintainers of the PHP core ensure that every bug fix has a passing unit test along with it. That would at least keep the dam holding back the flood intact.

justincormack 15y ago
Adding tests for bug fixes doesnt necessarily help when your code is in that state. I think you are better off looking for coverage on tests, and trying to write specs eg formalize the parser as mentioned. Probably a lot of tests now are from previous bugs, but the code has drifted and they have not been maintained.