The True Problem With PHP
blog.ircmaxell.com
blog.ircmaxell.com
The ##php IRC channel on freenode (1) is an absolutely incredible resource. I've idled in there for many years now and the amount of good, relevant, and accurate information that can be obtained in there is incredible. Whether you have been programming for 5 days or 5 years, simply hanging out in the channel for a couple of days can offer insights and tricks that you may have never known about.
Over time, the folks there have compiled an absolutely excellent Wiki (2) for developers; old and new. In addition, there is a wonderful list of general do's and don'ts for PHP application development. (3)
Time and time again, we get folks in there who are using outdated technologies (hello mysql_* functions) or just awful tutorials or resources and they get turned around in no time.
Disclaimer: as the author states, there are many self-described experts in PHP and they do, occasionally offer bad advice. However, it is rare for the bad advice to go unchecked in this IRC channel so I can still recommend it without worry.
[1] - http://freenode.net/
[2] - http://wiki.hashphp.org/Main_Page
[3] - http://hashphp.org/
I think this is the real problem of PHP.
It attracts people too stupid to realize that their own level of knowledge should make them avoid teaching others.
As soon as someone points out an issue they almost immediately switch to "LALALALALA I CAN'T HEAR YOU!!!".
There are many very, very smart people that try to teach others as a form of their own expression and learning. People coming from other programming languages that are extremely talented in that language, often take on this role as they are confident in their abilities. That doesn't make them stupid, nor should it disqualify them from attempting to teach or help others.
> As soon as someone points out an issue they almost immediately switch to "LALALALALA I CAN'T HEAR YOU!!!".
I don't think that's a fair assessment at all. In my experience dealing with precisely that situation, I find that most are actually very willing to accept and admit to their fault. Even in the chat room, over the many years I've been there, there are far more people willing to accept their incorrectness over people who take offense.
PHP wouldn't be this worse if this was what would actually be happening, because these people would assess the situation and take away the control from the PHP team, due to its inability to do its job.
More realistically, people see PHP and run away screaming. The only people using PHP are those unable to see how unbelievably bad the language and its libraries are designed and implemented.
> I find that most are actually very willing to accept and admit to their fault.
- So why is the standard library in such a bad shape?
- Why is the documentation in such a bad shape?
- Why aren't there any established processes in place to prevent repeating mistakes (see above)?
- Why are large parts of the implementation barely maintainable?
- Why is the ecosystem still in such a bad shape?
- Why is the core team spreading bad practices instead of good practices?
- Why is the language so unbelievable slow?
- Why is the runtime and the garbage collector of such bad quality that it is completely impossible to run sufficiently complex applications over a larger period of time?
> - Why is the documentation in such a bad shape?
The documentation is up-to-date AND in good shape.
> - Why aren't there any established processes in place to prevent repeating mistakes (see above)?
What kind of processes? The documentation clearly lays out pitfalls and problems to watch out for.
> - Why are large parts of the implementation barely maintainable?
What parts?
> - Why is the ecosystem still in such a bad shape?
What part of the ecosystem? It seems fine to me.
> - Why is the core team spreading bad practices instead of good practices?
Seriously, give me some examples of these bad practices, please.
> - Why is the language so unbelievable slow?
In comparison to what? For the class it is in, it is very fast.
> - Why is the runtime and the garbage collector of such bad quality that it is completely impossible to run sufficiently complex applications over a larger period of time?
Erm, I've run long running processes for years. There was once a problem with circular references but this has long since been resolved.
Also, you showed your lack of understanding of PHP in a previous response (http://news.ycombinator.com/item?id=4198984) to mine where you where unable to distinguish between the Apache and Cli PHP SAPIs.
What parts?
------------
Possibly the part that essentially required \ as a namespace separator. This was because ZE2 simply couldn't be coaxed to deal with a different separator, and no one has yet spearheaded a ZE3 to take the lessons learned over the last decade and revamp the internals to allow for more modularized growth/modifications.
Most other languages have had underlying VM changes which allow for better language enhancements. Every PHP language change in the last 12 years has had to work within the confines of the existing VM, and I've not seen any substantial changes to it in 12 years.
In comparison to what? For the class it is in, it is very fast.
PHP is what I would an intertwined language as quite often people don't separate PHP the language, PHP the included battery (aka the standard library), PHP the easy deployed script and PHP the web tool at core.
It's both a curse and a blessing IMHO. It easy to ignore the differences but hard to learn about them later and the official doc not really teach about it doesn't help. I am not say the doc is bad, just trading off clearly for easiness. It probably helped PHP grow so popular.
As for the quote, PHP the language _is_ slow but the mitigated by a fast standard library (mainly C function wrappers). That said, PHP 5.4 is faster than ever.
There are some real problems in the PHP community, like the terrible mismatch between the PHP core and PEAR developers, and the fact that nobody's got the guts to declare PEAR a failure, put it down, and start something new. However, other than that, the people I know involved with PHP are reasonable people.
For me the trouble w/ PHP is that it works too well.
I've got a small project w/ 40 hours budgeted for it, 20 of those are software dev, and 20 are corporate identity and marketing.
I have libraries that smooth over the worst flaws of PHP and answers to error handling, sysadmin, and all that. I know the odds are very good I can slap this thing onto one of my production servers, push the 'go' button, and have it work for 2 or 3 years before I need to look at it again.
Ruby may be nicer, and Java is better for computationally complex and intensive stuff (not this) but adding a new language to the mix probably means more hosting costs (maybe abother $60-120 a month) and probably turns that 20 hours to 60. It will take me a long time to have faith in the stability of another hosting system too.
The reality is I nail out quite a few of these mini projects, some of which succeed, and many of which just smoulder. With PHP I can get them done quick and done well and have low hosting costs and little maintenance burden.
To get me to switch you need to quit complaining about the faults of PHP and build my faith that your hosting system is a 'wooden round' that won't cause my 20-hour project to cost me 50+ hours a year in maintenance costs.
If you're interested in mentoring or being mentored, add yourself to the list. https://github.com/phpmentoring/phpmentoring.github.com/wiki...
The program has only been initialized 4 days ago and it has gotten quite a bit of interest.
Freenode: #phpmentoring
http://blogs.perl.org/users/mithaldu/2011/10/perl-tutorials-...
There, a perfect opportunity for language designers to shine. Nothing fancy, just fork and fix. No need to come up with new paradigms. Nothing to make you sweat. Just fork the damn thing and fix the warts with a scalpel.
It is and will be the most used language for web development. If that is not a shiny medal in your chest and a place in history books, I don't know what is.
Any takers?
Drop the dollar
Use + for str concat
Use . for class members
Use . for dicts
Use . for namespaces
Use : for key:value pairs
Fix needles and haystacks
Use camelCase for functions
Use arrays and dicts literals
Use list genereators
Use request and response objects
Objectify strings, lists and dicts
Feel free to add yours.
- Stop trying to turn PHP into another language. Millions of developers are perfectly fine with its syntax, deal with it.
Of course these things will all happen in time if the fixed version takes hold. But if you're willing to throw out PHP and start anew, you can have all of the above right now by learning Node, Rails, Django, etc.
I think the comment above about needing a Jeremy Ashkenas (that is, a CoffeeScript for PHP) is the only realistic way for a "fixed" PHP to succeed. There needs to be a smooth transition, and a FixedPHP-to-PHP5 compiler could provide it.
It is not about making it a completely different language, just about simplifying it, making our lives easier.
What's wrong about dropping the dollar sign for variables?
What's wrong about objectifying a string so our editor can popup all string functions on 'name'.?
What's wrong with using key:val instead of key=>val?
Saving one char at a time is a win, we are lazy beasts, you know it.
You typically see one of two responses - either call one of your columns "modified" or "created" and hack it in like that. Or, use PHP's built-in date() function, ignoring the issues that brings (e.g. the current timezone could be anything - not always what the database is operating under).
This is an ongoing problem, and is likely related to PHP's ease-of-use; for new users, it's easy to get a sense that you know more than you think you do, and give advice accordingly.
The bigger problem is that it keeps building upon itself. People who don't know better, taking advice at face value, then giving that advice increases the number of people writing crap code. Try searching for password storing advice, and you'll see masses of varients of md5('salty_' . $password);
>hash = md5('deliciously-salty-' + password)
Hehe, that's might be related to why I wrote one of the things and not the only thing ;-)
- Use the db schema to enforce a value: "ON INSERT/UPDATE CURRENT_TIMESTAMP". Note that doing so will not allow you to simply set an arbitrary column to the current timestamp
- Use the php `date()` function. Your server time should be UTC, your app time should be UTC, your datastore time should be UTC. Doing anything else is poor practice. And if you can't do this because your Sysadmin is stupid, fire him and get a new one. This is how the created/modified fields work.
- Use created/modified fields. These obviously won't work if you want some random field to be the current time that isn't actually the created/modified field, but I cannot for the life of me think of such a use-case.
- Use "DboSource::expression('NOW()');" as the value of the column. A little more verbose than just doing "NOW()", but at least it won't be interpreted as a string when saved by the "ORM".
Also, I recommend doing "md5($salt) . $password" to hash passwords. Set $salt to 4, I guarantee that is a random number. ;)
I think that this is advice that should never be given; it's too easy for someone else to change the timezone PHP uses somewhere else in the code. I agree that the servers should all be on UTC - and sync'd at that! - but it's unrealistic to hope that this will be the case in all instances; I've seen all kinds of weirdness from clients' codebases after taking their first steps off shared hosting / "my first VPS."
Use "DboSource::expression('NOW()');"
Basically, the only realistic option - and last time I searched (I admit, a while ago) really buried away ;)
I think the biggest problem with PHP is developers not truly understanding the API they are using, and then writing spaghetti code that happens to work.
Agree 100% with you. From some of the client code I've repaired, I've also stumbled over PHP developers apparently not understanding the very basics of programming, and crossing their fingers when it comes to running it ;)
Hack it in like that? CakePHP is convention over configuration, and the framework manages "modified" and "created" for you which is pretty nice. Not something I expected somebody to complain about, but perhaps I'm misunderstanding the issue.
I've found it hard to argue against PHP with my former bosses, due to this fact.
With Django 1.4's templates, you get more speed boost on setting up each app. With 'manage.py runserver', you don't even have to mess with Apache/Nginx to get running.
Regardless, comparing "PHP" to Django isn't particularly fair, even though I would argue that it isn't as one-sided as you make out. You can get started in Flask in slightly more than the time it takes to type 'pip install flask'.
If you're baselining PHP to Python, then know that Python has a much greater penetration on Unix servers, though arguably 'web hosting providers' are also very likely to have PHP installed (if it isn't dedicated).
Since you brought up Django, how long does it take to get started with CodeIgniter or Symfony (a better comparison to Django)?
Though I will say that I read 'getting started' as the cost of getting started on a new project, not 'your very first' project. In that regard, sure, PHP is easier. It gets that way by encouraging programming idioms that most other languages actively discourage.
I understand the argument for would-be developers to get started with PHP. That's not too far off from how I got my introduction into web programming, but I have a hard time believing that developing developers choose PHP over Python or Ruby because it's easier to install.
But if, say, I want to try out a new JS library or widget, I'm pretty likely to just throw a PHP script in my webroot and use that, instead of firing up a full-blown Django project.
The time from deciding to write some HTML or JavaScript or whatever to actually writing it in a PHP script? Basically nothing.
I'm not trying to be snarky, but I feel like I'm missing something. How would creating an 'index.php' be any faster than an 'index.py' with Flask or just using Python directly?
Again, comparing it to Django isn't exactly fair. I wouldn't see many people standing up a full CodeIgniter setup for that either.
If there were something that would allow me to spin up local application and work with my existing, already running Apache processes, I could move away from PHP.
Then I just invoke it with "shotgun rest.rb" and hit http://localhost:9393/ and I'm up and running. It's not running through Apache, but it's not really significantly more difficult than PHP prototyping.
curl -d "foo[bar]=1&foo[baz]=hello%20there" http://localhost:9393/foos
{"result":"success"}
curl http://localhost:9393/foos/1
{"bar":"1","baz":"hello there","id":"1"}
[1] http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...
[2] https://bugs.php.net/bug.php?id=50696 https://bugs.php.net/bug.php?id=18556
It seems the HN community tends to over-value language design and under-value low barriers to adoption.
Why would I optimize for barriers to adoption? I don't need my language of choice to be popular to get away with using it, especially if I'm building one of those Web thingers everyone likes to make these days.
What I do need is a language I can be productive in. All else being equal, the less a language surprises me with inconsistent or outright broken behavior, the more productive I can be with it.
From http://www.paulgraham.com/avg.html:
"Robert and I both knew Lisp well, and we couldn't see any reason not to trust our instincts and go with Lisp. We knew that everyone else was writing their software in C++ or Perl. But we also knew that that didn't mean anything. If you chose technology that way, you'd be running Windows. When you choose technology, you have to ignore what other people are doing, and consider only what will work the best."
So, yes: I can't speak for everyone, but I would rather use a well designed language with poor adoption than a poorly designed language that's been widely adopted.
Astronauts need to come down to earth and help stupid people build better blinking tags for their lolcats, not push them to write lolcats in monads with concurrency.
So, whether astronauts like it or not, a simpler un-evented node.js would sell like hotcakes (because it is js, not because it is evented), while a cleaner, facelifted php will sell even more.
Fork php, use + for string concatenating, . for class members, fix haystacks and needles, add [1,2,3] and {a:1,b:2} as simple data structs, that's all lolcats need.
Learn to serve your customers, even if they are stupid.
My Erlang isn't bad, but it would be madness for me to suggest it to a client. What happens if I get run over by a bus tomorrow, or we need to bring extra coders on board?
Erlang, for all its many, many favours, is just not appropriate for the average-client-on-the-street.
I realise that you didn't use Erlang as an example, but there's a reason why there's so much work for competent PHP programmers, and it's not stupidity.
Not sure how node.js can be 'simpler' though, it's pretty much coding in pure JavaScript which is a simple language itself?
rows = db.select('users')
db.select('users',function(data){/*callabck*/},function(error){/*error*/})
90% of the time I need the template when I read it
view = template('index.html')
text = getFile('setup.yaml')
html = webget('google.com')
Fork it, drop the (CSM) stuff and conquer that 90% who would like to use JS on the server.
IO is slow, Node is evented IO, the requests come in and the requests (to the database) go out, the data comes in and the result is rendered to the client. Node deals with requests.
But let's say it was made to work like you request, and the docs were changed to reflect that. People learn they could throw some code in a file and call it node.js. (I've done that, using a fastcgi server implementation and adding a hander for it on a bluehost account.)
So now you have PHP but with Javascript as it's syntax, your developers build applications the way they do in PHP, you call Node slow and a thread like this launches on HN saying how bad the language is and how somebody should fix that.
So yes, simplify JS on the server to act like PHP and use node for servers and other stuff. Name it differently if you want so they don't call node slow. V8CGI is the closest to a deliciously simple JS implementation on the server I've seen. Take a look at it for some ideas.
-- Democratic People's Republic of Korea
(Incidentally, I found it again by Googling for "worst C++ tutorial"—for me, it was the first match.)
So yes, someone, please do throw some good advice out there to help drown out the bad!
You only have to browse code on phpclasses.org (the most popular PHP code contribution site I think?) to see that there is something very very wrong with how PHP code is developed.
Also the comments left in the PHP documentation don't seem to be moderated on code quality and a lot of bad practice has slipped in.
To be fair, there are plenty of junk code sites out there. I'm amazed that http://www.codeproject.com still appears to be going strong.
It really doesn't help PHP that a site as popular as phpclasses has such a large degree of inferior code.
Popular in that everyone knows its name and knows not to ever use it. It's an absolutely awful site that's been awful for an entire decade. Most of the code being uploaded there these days is from indian and brazilian developers.
All the good PHP libraries are on github and shared socially.
Sure, the page self-declares that it is "mainly used to track internal development of the PHP project", but its a wiki. We can change that.
In 2012, the availability of hosting and ease of deploy is no longer a reason not to use Ruby, Python, or whatever.
Where would one find a good tutorial site?
Its been said before, and I'll say it again: if you dont like PHP switch to something better, if there isn't anything better make something better.
The problem with _anything_ big enough to have a fringe is always the people at the fringes.
I'm going to get back to work and continue coding in my chosen tool, PHP, see you all at the finish line because whatever your tool, we'll all get there in the end.
Whilst I agree critical analysis is great, general discussion can be somewhat impressionable on newcomers. Whether you realize it or not, PHP bashing / over praising will been seen by newcomers and they won't know where the foundation lies.
Why must we push ideas and concepts onto people, why can't we give our points and let people make up their own mind. Personally I don't want to drift through life with people telling me what to use or what not to use, I'd prefer to see the points and make up my own mind without being preached to.
Like those, who failed for years to actually consult the results of the test suite before shipping a new release? http://gcov.php.net/viewer.php?version=PHP_5_4
Like those who change stuff incompatibly to the worse, while introducing security holes? http://php.net/manual/en/function.is-a.php https://bugs.php.net/bug.php?id=55475
Like those were security fixes create even larger holes? http://thexploit.com/secdev/critical-php-remote-vulnerabilit...
Like those who can't program a sane line of code in the language PHP is written in? "OMG, this calculation overflows, let's replace the int by an float!"
You can't make that shit up. I have nothing against stupid people, but against stupid people who fight against every kind of process who could prevent their own stupidity like
- "learning from mistakes",
- "learning the language they actually program in",
- "handling bug reports in a way it doesn't alienate reporters" or
- "having a decent test coverage".
Instead of thinking about yet-another-documentation site, what about fixing the devastating quality of their API documentation (especially the comments)?
Though this one isn't far off: https://bugs.php.net/bug.php?id=18556.
You can point out all the flaws, but that's like pointing out the flaws in McDonald's. Sure it's cheap food, but it's consistently cheap and there's a much larger market for cheap food than gourmet food.
Perhaps "other language" developers should start thinking of themselves as gourmet chefs. And like gourmet chefs, not many people can afford their products in the real world.
How exactly? I always see vague assertions that PHP is somehow better for "stuff I do in the real world", but nothing concrete. Guess what, the rest of the world is real too. I am not writing haskell code for my imaginary friend, I am writing it for real users to use in the real world, and a real business relies on it to provide real people with real incomes to feed their real families. How exactly would PHP be "more efficient all around"?
People have sentimental feelings about McDonald's, prefer the style of fries, etc. - it isn't that McDonald's products are incomparable or irreplaceable and that the only alternative is expensive, difficult "gourmet" food.
The problem with English is that most of the people speaking it, writing it, or teaching it - collectively what I shall call the 'fringe' - could not so much as pen a tolerable introduction to a Penguin Classics paperback.
This is 2012, people. Programming isn't just a profession, it's an everyday skill that everyone should learn, regardless of how badly. PHP is a great enabler for this - and I endorse this direction completely.
Smoking isn't just a profession, it's an everyday skill
that everyone should learn, regardless of how badly.
A cigarette is a great enabler for this - and I endorse
this direction completely.
-- Your friendly tobacco association.I have worked with a lot of people and mentored quite a few at companies I've worked at. Some were designers, some weren't even in the IT departments. Any that wanted to learn something about we programming I lead in the direction of PHP which I cut me teeth on before moving onto other things (currently Scala). They could get a dev environment up and running in no time, and better than that they could actually host something they did on shared hosting for practically nothing (or actually nothing as I sometimes gave people sandboxes in my hosting).
PHP is a gentle introduction to server concepts and have a fairly simple and not-too abstract syntax. Yes yes, when you really look at it there are some fairly glaring inconsistencies but the reality these people were not at the stage where they would notice or care.
It's also embarrassing to me as a professional who, like most, believe that some knowledge in programming will be of great use to people (in business or otherwise) and try my best to support anyone I know wanting to learn something or better themselves that this attitude is so common and outspoken with no logical justification or attempt at rational counter argument. Programming is hard. Good programming is harder, and the levels at which some of us seem to hold everyone around us (and yet somehow I doubt they hold themselves to every minute at work) are unrealistic and can push people further away than do what we should be aiming for which is bringing people in.
I'm really proud of every one of the people who stuck with learning and letting me help them and I think it's appalling to belittle their efforts indirectly with comments like this.
That doesn't mean we have to be happy with the shitty way things are currently done.
The first reason is because it's at the bottom of one of the most contentious issues facing modern man: the question of whether we are ultimately mechanical in nature, and what that means moving forward. To understand this you have to understand what machines are, and what they do. It also helps on other contentious matters like understanding how natural selection works -- and that natural selection is possible -- to explain simple genetic algorithms and how 'fitness functions' can be used to indirectly design complex structures.
The second reason is that everybody today owns several computers. The single biggest thing that I use JavaScript for is GreaseMonkey scripts to make my favorite web sites do what I expect them to do. I think a lot of frustration comes from tiny things which we can't control -- and that computers give us a tremendous opportunity to control those tiny things.
Then they go on to teach others—other who, just starting out themselves, have no idea they're learning from someone who knows barely any more than they do. Or, they go on and get jobs doing this, and their very amateur code end up out in the wild.
I hate this effect because I'm definitely a fan of anyone who wants to being able to experiment with programming. I got my own start screwing around with code on my family's computers, probably like a lot of us here. Thankfully, I started so young that it was more than a decade before I got a job writing code. I even learned a thing or two in that time!
Of course, I also started with BASIC, then jumped to assembly for two different CPUs before moving onto C and a handful of other languages. Enough curiosity and dedication can get you through less newbie-friendly languages.
Maybe requiring that curiosity and dedication as a barrier to entry is a good thing. I think both are absolutely required, even in 2012, to become even a competent programmer.
PHP lets them do that without having to learn anything more complex. Why spend days or weeks learning something when you can work out how to do what you need to do in hours?
That said, I don't think it's about this. I think it's about respect. And people, right now, just don't respect PHP.
Did you read the article ?
> But on the fringes, there are a lot of people who are writing articles, tutorials, and posts designed to help beginners learn the language (and usually how to program). The problem with this is that the majority of those authors frankly don't have a clue what they are talking about.
It's the most ubiquitous language, which leads to being the easiest to start with. Thing is, if people learn it wrong they're going to churn out crap. That's a vicious cycle.
If someone were to write a "Problems with PHP and Proper Password Hashing" post it would be #1 for weeks!
I would be more interested about an article titled "From Zend Framework to Django" (or whatever language/framework) than the thousandth article "Your language is bad and you should feel bad".
Don't like it? Don't use it. Move along.