Here's a pitfall I know from briefly trying to improve PHP, and having developed in it:
The syntax definition is used for some types of basic type-checking.
I'm completely serious.
Because of this, if you try to do a combination of property/array/etc. accesses that the grammar designers didn't envision, you'll get a very cryptic error. For example, this (which runs an anonymous function dereferenced from an array dereferencing from a static member of a class):
self::$views[$path]();
Doesn't work. It assumes that the result of self::$views[$path] is a string, and then complains there is no function with that name. (Yes, you can execute strings with names of functions, as if they were that function...) But this:
Life is too short to read another half-hearted defense of a terrible language. This author lost me when he started out by only acknowledging the critiques of PHP that he could handwave away. If he actually had a coherent response to "Fractal Of Bad Design," that would be something worth reading on its own.
To the author: doesn't the fact that you have to point out all of these things to avoid say something to you about core issues with the language?
Only 1 paragraph deals with PHP's reputation, the rest is geared towards those who actually want to learn PHP and/or improve their skills.
To you: doesn't the fact that you myopically dismissed the entire article due to a single paragraph say something about you? Why are you looking for a flamewar where one doesn't exist?
I get it -- you don't like PHP. That's your prerogative, and you're of course entitled to it, but this article isn't just another skirmishing ground for the flamewar that is "PHP SUCKS" vs. "NO IT DOESN'T". Rather, it looks to me to be more of a braindump from a PHP dev looking to enlighten new PHP devs with what he's learned.
Is that so patently offensive to you that you have to attempt and interject the played-out flamewar that is now a decade old?
>Only 1 paragraph deals with PHP's reputation, the rest is geared towards those who actually want to learn PHP and/or improve their skills.
Do we really expect the language elitists to actually read articles now? Just say something bad about PHP here and you'll get 20 instant upvotes. We're getting as bad as reddit here.
As someone who uses PHP, I found this article very enlightening.
No. Fact is, the language is used by a lot of people who have no clue what they're doing. This article is not for them. Come to think of it, it's not for you either. It's for people who use PHP with some degree of competence.
I think PHP is to a large degree a victim of its own success. The runtime's ubiquity means that a lot of very incompetent people are fiddling around with things they don't understand. If you look at, say, PHP-related questions on Stack Overflow, you'll notice they are of extremely low quality that have nothing to do with PHP itself, but have everything to do with the person behind them not understanding the simplest things about programming.
Simply put, the strength of PHP is also it's greatest failure. It's got a very low barrier for entry, but a very high learning curve for doing things correctly (efficiently, securely, etc...).
I know I've fallen into many of the traditional PHP traps simply due to what I call language laziness. "Why do it this way when the other way is so much faster". PHP allows you to do quite a few things wrong very quickly.
I'm a closet PHP fan, but not compared to "better" languages like Python.
I agree that the vast majority of PHP code is terrible and that the language itself is full of annoying flaws but take a look at Symfony 2 if you care to. It's a well architectured framework which uses best practices borrowed from other languages/frameworks and ends up as something coherent, well designed, reliable and a pleasure to work with.
There have been numerous responses already that debunk many of the claims presented there. Suffice it to say, you came to this with your mind already made, and nothing is going to change it.
You don’t even need serverside debuggers or fancy instrumentation to achieve this. The function microtime() returns a timestamp in microseconds. This makes it easy for you to check the passage of time at key points during your application’s execution path.
Good point, I appended that link to the profiling section.
I noticed there is some discontent with my use of the microtime() method. It's not intended to replace a serious debugger/profiler, but it is something that's available in any PHP environment for quick performance checks.
Very long, and I don't think the prose style fits the information you're trying to deliver.
It's a pretty good attempt, though. I would have liked to see more links for more information, and you don't mention packagist at all.
Either way, a good start. Knowing about these ideas, and knowing why to care about them, is the first step to becoming a better programmer, regardless of the language.
That's a nice way of saying my writing style sucks, but it's still a welcome (and probably appropriate) critique. I'm open to suggestions on improvements.
It's true that I didn't include a lot of links to more advanced frameworks and libraries, mainly because I wanted to limit the scope of the article to the basics of the PHP runtime. I also think that in order to avoid mistakes people should think more about those basics, even when they happen inside convenient library methods.
If you think there are links to essentials that should be in there, you're welcome to contribute them in the comments.
I liked your writing style, it actually kept me engaged until the end. I guess it also helped that I had an interest since I'll be supporting php applications for the first time in 5 years.
Packagist is important because if you don't mention it they're going to use PEAR or PECL or (gasp) Zend Framework, all of which are generally inferior to what is offered on Packagist.
Avoid making a database connection when your request doesn’t need it. And when your request does need it, you should prefer mysql_pconnect() over mysql_connect() for the simple reason that it potentially shaves some execution time off the connection part.
Actually you should avoid using both mysql_pconnect and mysql_connect, because they're both functions from the deprecated old mysql library of database functions. The preferred way to deal with MySQL databases in 2012 is to use either PDO (http://php.net/manual/en/book.pdo.php) or the "improved MySQL" library (http://php.net/manual/en/book.mysqli.php), both of which are better architected and give you access to things like prepared statements that the old mysql library does not.
There's really no good reason to be using the old mysql library at this point. Unfortunately, however, there's a vast amount of ancient PHP tutorials, code snippets, and other copypasta floating around out there that uses it, so people who don't know better still pick it up.
That's absolutely true, but I was using the generic MySQL lib as a kind of common-ground illustration. The actual point translates just as well to any other DB library. Establishing a connection to the server and issuing queries takes a lot of time and often times it's done for all requests even if some of them don't need fresh DB data.
Yeah, except you're talking about PHP Pitfalls and failed to mention and then fell victim to and perpetuated the #1 Pitfall of PHP: Legacy Cruft.
PHP's libraries are full of Legacy Cruft that any other sane system would have deprecated and eliminated during a major revision transition.
The wholly inefficient and unsafe legacy MySQL lib is one of the primary examples.
Good on you for at least mentioning parameterized statements, but you didn't really follow through. You then go on to confuse the situation by talking about the old API.
Instead, you should have just said "Using this old API is a horrible idea. Don't. Ignore every guide or tutorial that does."
PHP has evolved considerably from its roots. The #1 problem with PHP is that it still lives in its parent's basement and hangs out with the same losers it met in Kindergarten.
You still do. They do break things with each major release, sometimes in a big way. (Fatal-by-default errors for some types of "bad" OOP code and not setting the timezone in PHP 5.4, for example). Just not as much as some other languages.
I don't really agree with that criticism. The first DB example I used was all about parameterized queries. Still, that doesn't absolve people from at least thinking about escaping stuff, that's why this other example is in there. But I get your point, I'll append the section to make it clearer why I'm referencing a legacy library.
HA - pitfalls include needlessly using low level functionality when any number of hundreds of higher level (to varying degrees) frameworks and libraries that would abstract away most of these problems, and easily installed/found with composer/packagist. Why most PHP'ers ever need to write a mysql(i)_* function is beyond me. There are plenty of perfectly good wheels out there and you're not re-inventing a better on.
That's assuming that the users have the server access to install the packages or an up-to-date PHP interpreter. A lot of the appeal of PHP is that it is available on cheap shared hosting, which until recently would not be guaranteed to have PDO, mysqli and friends installed. If you have access to a VPS of some sort, you can easily install such things, but in that case you can also use a different language.
The syntax definition is used for some types of basic type-checking.
I'm completely serious.
Because of this, if you try to do a combination of property/array/etc. accesses that the grammar designers didn't envision, you'll get a very cryptic error. For example, this (which runs an anonymous function dereferenced from an array dereferencing from a static member of a class):
Doesn't work. It assumes that the result of self::$views[$path] is a string, and then complains there is no function with that name. (Yes, you can execute strings with names of functions, as if they were that function...) But this: Does work.Please, don't use PHP. It's horrible.