PHP is a server-side HTML-embedded scripting language. It has a very C-like syntax with some handy Perl'isms tossed in. It also supports all the popular SQL engines including MySQL which runs Everything. In fact, one could write Everything in PHP quite easily.

Maybe it has changed, but according to www.zend.com, PHP was originally PHP-tools, at which point PHP stood for Personal Home Page Tools. Rasmus Lerdorf used a set of CGI scripts that he wrote to track people reading his resume online. It was then converted to a set of Perl wrappers for C calls and opensourced.

Referenced from http://www.zend.com/zend/hof/rasmus.php
Sure, it's a health insurance plan, and it's also a server-side programming language, but it's also a 6502 instruction that pushes the flags onto the stack.
  • Function: Flags => Stack
  • Updates flags: None
  • Opcode numbers:
    impl  $08 (3 cycles)
    

Similar: PLP | PHA
See also: 6502 instructions | 6502 addressing modes

(acronym) PHP Hypertext Preprocessor

Essentially, PHP is a very flexible, very useful web development tool, designed to take on the tasks of serving up dynamic content. Capable of running on IIS, Apache, and probably a slew of other web servers, PHP is readily and freely availible to all those interested.

A frequent gripe had against PHP is security -- Since PHP is so simple that relatively inexperienced computer users can still effectively employ it, PHP code has a bit of a bad reputation for having more holes than swiss cheese. Heading the crowd of these security complaints is PHP's behavior of automatically registering global variables for anything passed by the browser. Although this behavior can be changed in the configuration file with the line "register_globals=off", it is on by default.

In other words, if I request:
http://site/file.php?some_var=blah
Then as soon as file.php starts executing, there's a global variable waiting for me called $some_var, whose contents are "blah." While incredibly handy when you just want to whip up a quick little something, this gets to be a bit troublesome when you have code like this example:

<?php
if($userPasswd==$sitePasswd)
 $logged_in=1;
[...]
if($logged_in==1)
 something_secure();
?>

Our attacker need only put ?logged_in=1 on the URL, and he automatically qualifies as logged in. While this simple example is so bone-headed that no one in their right minds would be likely to fall for it, more subtle variants of it may well -- and generally do -- come back to haunt the unsuspectiing programmer.

Another critical point many Perl advocates have against PHP is bloat and speed -- By default, PHP has out-of-the-box support for a myriad of protocols, features, and functions -- some of which further reinforce the argument against PHP's security. While I haven't run any serious tests, my general feeling has been that PHP is not as fast as Perl. This may be quite wrong, and I have only measured this through scripts which perform millions of operations. However, I have seen many arguments against PHP which mention this performance difference. It would definitely be interesting to see a more scientific exploration of the matter.

PHP has a very simplistic approach to arrays, hashes, and objects which may well be useful for teaching beginning programming. Much like Perl, in which the line between integers and strings becomes blurred, PHP has a rather context-driven approach to the interpretation of a value. Unlike Perl, where hashes, arrays, and scalars have seperate identifiers (%, @, and $, respectively), PHP variables all start with a $. All PHP arrays are hashes, regardless of how you refer to them. The following construct is perfectly legal in PHP:

$arr[0]=0
$arr[1]=1
$arr[2]=2
$arr[3]=3
$arr[4]=4
[...]
$arr["ten"]="TEN";

PHP adequately supports classes, although its lack of destructors gets a bit annoying from time to time. PHP is exceptionally well-documented -- The PHP web site (http://www.php.net) maintains a complete searchable list of built-in functions, with parameters, more detailed discussion, user comments, and an surprisingly useful list of related functions. All-in-all, it puts Man pages to shame. Additionally, the PHP manual is a wealth of information, and comes in a variety of formats (including, as I found out to my glee, iSilo for PDAs).

Despite its intimidating security problems, I love PHP. It takes some discipline and know-how to really tighten security with it, but I find that you can take care of the global variable problem while still easily maintaining the swift development times, compact code, and readability that make PHP so attractive.

This is the genealogy of the programming language PHP:

PHP is a child of Perl and C.
PHP was first known as PHP/FI in year 1995.
It became PHP/FI 2 in year 1997.
It became PHP 3.0 in year 1998.
It became PHP 4.0 in year 2000.
It became PHP 5.0 in year 2004.

Thanks Peej and motiz88!

This genealogy is brought to you by the Programming Languages Genealogy Project. Please send comments to thbz.

PHP is a language that's become popular for web apps. Some of PHP's notable non-features include:

  • No Namespaces: PHP doesn't have a concept of namespace, which means it's got a load of functions in "core", and addon packages have to be careful not to step on each other.
  • No anonymous functions: Well, not really, anyway. There's create_function but it works at runtime rather than compile-time, which leads to problems.
  • Wonky arrays: PHP's array type tries to combine arrays and hashes, but it isn't very good at either. There are a dozen variants of the array functions differing only in how they combine "numbered" and "associative" elements.
  • Wonky references: PHP doesn't have references, despite the documentation. It has a way to make aliases in the symbol table, and a (buggy) version of pass-by-reference, but it doesn't have first-class references.
  • Database inconsistencies: The standard set of database functions doesn't just provide a completely different interface for each database engine; it's also designed to encourage SQL injection-type security holes
  • False security: The misnamed "magic quotes" are supposed to be a magic bullet against injection attacks, but what they really do is corrupt data and introduce incompatibilities between servers. And they don't even protect from the most interesting attacks
  • Strapped-on OO PHP certainly isn't the only language guilty of having OO added as an afterthought, but it's got to be the worst. Take a look at the PHP annotated manual if you want to get an idea of the problems is has with binding time, derived classes not working as expected, and much more :)
  • Log in or register to write something here or to contact authors.