Php Pros And Cons

For a description of PHP see PhpLanguage

Pros

It's a quick and easy server side scripting language for web development and general use.
Large community, widely used. Most problems faced by a web developer have pre existing solutions.
It works well with databases, file systems, images, et cetera.
It has garbage collection, and a dynamic, stretch to fit container type, which obviates the bookkeeping needed in static languages. Moreover , the single catch-all container, (known as an array, but doubling up as a hash/dictionary) is a simpler and more refactorable than the alternatives in some rival dynamic languages, eg PERL's profusion of sigilused types.
It has regular expression support (Both GNU and PCRE. The GNU ereg* functions are deprecated, but that's been the case for ~10 years now.)
It has extensive database support. There are more then a few 3rd party (free!) Database Abstraction Api's available to it. SqLite support is in the standard library.
It integrates with its environment. You can execute a system command by surrounding it with `s (backtick operator). There is extensive support for interacting with named pipes and the Apache API. Take that, CommonLisp!
There is a CLI interpreter available that makes it very nice to write ShellScripts in PHP.
The syntax is familiar to the myriad programmers that know any other C based language.
Being one of the most popular server side scripting languages available, there are quite a few very useful and free products available. There is also a lot of free support available.
It is interpreted, so your build cycle is super short. If you need the speed of a compiled language, you can use a compiler with it, or you can write what you need in C, and use the excellent C<->PHP interface.
It runs well on *nix or Windows under most any web server (Apache, nginx, IIS...) and is widely available on cheap (or even free) hosting and many people already have access to it.
Released under the PHP Licence, which is very BSD like.
The online manual is widely regarded to be the best of any programming language. (see below)
There is an extremely large body of built in functions, and there is an extension repository with even more.
Shallow learning curve for simple tasks. <?php echo "Hello world!"; ?> Place this in a file with the .php extension somewhere on your Apache server, and point your web browser to that file. Nothing to compile, no configuration files to edit if everything has already been configured for you, no libraries to hunt down. (in other words, it's very easy to deploy) You don't even have to fire up the interpreter for hello world, just type 'Hello World' into a file with a .php extension.
Most php scripts run on different operating systems with a minimum of tweaking. The configs (php.ini) are generally different across platforms. But for the most part, it's about as portable as C I'd say. Note that files can be referenced using / in win32 php. Also, you can use the constants PATH_SEPARATOR and DIRECTORY_SEPARATOR (and PHP_EOL)
Shared-Nothing architecture is easy to scale. Just throw more hardware at it.
It's popular and common

Pro or Con depending on where you come from

as of 5.3.0 PHP now supports namespaces!
- Using "\" as the marker? Ick!
- The problem may be that there are not enough symbols in the top row of the keyboard. Which "easy" symbols we prefer be allocated to what may depend on one's coding style or domain such that we can't make everybody happy at the same time. We'd have to rob Peter to pay Paul.
PHP is weakly and dynamically typed (See WeakAndStrongTyping) (Maybe this should be two distinct points. See TypingQuadrant.)
Zero-based indexing
Adjustable language "rules" and environment. Creates some inconsistency from shop-to-shop, but allows customization to local needs/preferences.
Uses much of C-style syntax (Pros: ItsNotTimeToDumpCeeSyntax; Cons: ItsTimeToDumpCeeSyntax)
String concatenation and arithmetic addition are not overloaded like they are in JavaScript. ("." for concatenation and "+" for addition. Personally I like the separation. But I'd like to see the dot used for object references instead of "->", meaning I'd wish they'd choose another concatenation symbol.)

Cons

Global configuration parameters can change language semantics, complicating deployment and portability. However, most of these can be set at numerous levels: per-virtual host, per-directory, and even within a single script file, by using site-specific php.ini files, directory-specific .htaccess files, and ini_set().
Plenty of special purpose forms, but insufficient general purpose forms. Can someone explain what "special purpose forms" are for me?
Lacks named parameters, which have to be simulated with associative arrays or other techniques. I miss named parameters.
- of course foo($b=3, $a=4); is perfectly valid, as the expressions are evaluated, could be helpful to remember which is which, but very bad if you got them in the wrong order.
- That's still positional more or less. For example, you can't have defaults for non-mentioned parameters. At best it "documents" positional parameters. It also risks clobbering same-named variables.
Existing database API's hard-wire DB vendor names into code. (It is easy to write your own procedural or OOP wrappers, however, to make swapping DB vendor easier.) This is only if you choose to use the built-in API's, rather then using one of the many free database abstraction API's. Arguably, there already is an abstraction API in PHP, using the PEAR DB library or even PHP's native PDO extension.
Register Globals - This is a known issue with PHP, and newer versions (PHP 4.1 onwards) do not allow this by default. "Register globals" is a configuration setting that takes all Get, Post, File Upload, Cookie and Session vars, and put them in the global scope. This mode of working with PHP has been deprecated. Therefore no longer a con It's actually been removed completely as of PHP 5.4.0
Constantly changing. There hasn't been a release of PHP that didn't have a number of problems. The only way to get rid of them is to upgrade, but then you get new problems, because they don't have separate stable and development branches. Is this fair? does every language not have its own fair share of problems? Also, in my experience, the language itself seems pretty stable, but the extensions are the ones with the problems, which sounds about right anyway...) Or rather, the constant changes require you to get updates for security holes if you write cruddy code.
- The opposite is true. The reluctance of the core devs to add BC breaks is well documented on the php.internals mailing list
Ugly and unpredictable type system.
- This is not about the type system being dynamic. SchemeLanguage, for example, has a very predictable and quite clean type system.
- One specific annoyance is that too many functions require the use of triple equals (===), such as the "strpos" function. It should use one-based indexing or some other approach. Library operations should not rely on the somewhat hidden "type tag" of each variable (TagFreeTypingRoadMap).
- Type casting and other conversion mechanisms are arbitrary and inconsistent, not to mention they suck out loud. Debugging type conversion issues takes an inordinate (see? see what I did there? hah, hah) amount of time because you can't get a clean answer from print or var_dump or any other conventional debugging technique. Blech.
Inconsistent function names in the standard library: underscores (isset vs is_null), abbreviations (call_user_func vs create_function), etc. This, plus all of the points above make it nearly impossible to internalize much of the standard library, necessitating very frequent consultation with the API while programming. Also inconsistent parameter orders for common functions: in_array($needle, $haystack) vs strpos($haystack, $needle).
Objects are CallByValue by default, which is the opposite of most languages and catches lots of programmers off guard. (PHP5 and later default to call by reference)
Scoping is -- well, more like there is no scoping. There are really only ever two scopes: global and a function's scope. Both are completely separate and to access the global scope from within a function, you must use the global keyword explicitly per global variable. Within any other brace-delimited block, variables persist beyond the closing brace:

  ...
  // Example PPAC-01
  if (true) {
$a = 1;  // assume this is a new variable $a
  }
  echo $a;  // in every other language but PHP, this is an invalid reference
  ...

Scoping Flaws

Regarding Example PPAC-01, this is part of the dynamic nature of PHP. I don't necessarily consider it a "flaw". Dynamic declaration is a design decision that has pros and cons. (Decent "lint" tools can point out suspicious usage, similar to a compiler.)

No it's not, it's a serious design flaw. The language designers barely know how to program -- and this is what you get when you let non-programmers design a programming language.

Braces, therefore, don't introduce new scopes. In fact, there is no way of introducing new scopes in PHP apart from function declarations, which as noted before, doesn't even work like you would expect.

I'm not sure "not working the way it does in other languages" is by itself a flaw. The feature can be evaluated both on its own merits without assuming knowledge of other languages, and as compared to what a newbie to the language typically expects based on exposure to other languages. Removing that kind of dynamism may "fix" one class of problems, but may create other problems or limit dynamism for other classes of usage patterns. WaterbedTheory.

Nested function declarations also don't do what you would expect since there are no local scopes. They are used explicitly for the side effect of declaring a new function in the global scope, which granted, can be useful for keeping the global scope clean since there's no namespaces. However, this is unnecessarily hobbled by the lack of lexical scoping, because there's no way to reference variables from outside the function declaration unless they're global:

  function foo($a) {
...
function bar() {
echo $a;  // $a is assumed to be a new variable; this echoes nothing.
}
  }

That's a bummer. I really miss Pascal-style nested function scope.

Whether optional positional parameters are allowed depends on a global setting that bundles other unrelated settings. Perhaps if optional named parameters were added (above), this would not be an issue.
The dollar sign is not really necessary for variables, and one keeps forgetting it if they work with CeeLanguage, JavaLanguage, JavaScript, etc. A dollar sign can still work inside of double-quoted strings without requiring it to also work outside, so in-quote expansion is not a justification.

Work enough with PHP and you forget not to use it in other languages. It does make variables easy to spot, particularly constructions with variable variables and variable functions that would need some other syntactical construction if they didn't use it.

Addendum

Some people think that http://www.ukuug.org/events/linux2002/papers/html/php/index.html is a complete treatment of PHP's suitability for "non-trivial applications". The article, however, is full of misconceptions, a few of which need to be cleared up.

The article does not address the question of whether PHP scales. It simply describes specific problems the author had with PHP, mainly resulting from his own misconceptions
Separation of Presentation from Business Logic: most experienced PHP developers are aware of this issue and coding styles and template engines have evolved to deal with it. See SeparateDomainFromPresentation and http://wact.sf.net/index.php/TemplateView
- PHP is a template engine. You don't need to use a separate thing unless you're working with designers. I usually use a reverse header/implementation system where PHP code files include a common PHP template file that consists mostly of HTML and PHP echo statements.
Redefine functions: PHP will throw a fatal error if you redefine a function that already exists (built-in or user defined). This is not new and raises serious doubts about the authors use of PHP. It also suggests a determined procedural coder while PHP provides a (Java like) class / OOP syntax which could have been used to avoid most namespace issues.
Deployment Problems: although there are truisms here, experience with PHP will teach the developer how to navigate them (and most issues have been described / documented numerous times). PHP remains extremely easy to deploy, compared to say mod_perl or Java + endless XML descriptors.
Mixing or arrays and hashes: programming theory suggests this is "insane". In practice it isn't an issue. The prime use of arrays in PHP is as a temporary store for a row from a database result set. Sorting operations, for example, would be done with SQL. PHP isn't a general purpose language but geared primarily to web applications. Data doesn't persist between requests. Some kind of light-duty non-persistent table structure/API included with the language would be nice, similar to what AllaireColdFusion has. PHP PDO has reasonably good support for SqLite, and PHP6 will have APC built in (http://www.php.net/~derick/meeting-notes.html#add-an-opcode-cache-to-the-distribution-apc) and of course there is $_SESSION
Variable scoping: the author has failed to understand scope in PHP and is frustrated by why the "Perl way" doesn't work in PHP. From inside a PHP function scope, the global scope, unless specifically addressed, is not available. No need for shift - arguments are declared in the function declaration (like most C based languages other than Perl). Oh and never use global
Plus loads more.

Conclusion The author needs to learn OOP and stop hacking in Perl.

OOP is over-sold.

OOP is under-comprehended, which leads to people concluding that it's over-sold. -- MarkTaylor 23 Oct 2004. Sorry, Mark, total nonsense. OOP is not a SilverBullet nor a GoldenHammer. It shall be superceded, and let us hope very soon.

If it is so darned hard to "get", that should count against it. How do you know that you don't "get" perl?

The online manual is widely regarded to be the best of any programming language.

For example http://www.php.net/strlen

Can you provide some data points here? I don't regard the PHP online manual to be anything special. I find many parts of it heavily underspecified; the user-contributed comments, when they aren't obsolete or flat-out wrong, are a pain to wade through. I can immediately think of at least two "online manuals" that I consider better than PHP's. One consists of the Java API documentation and the Java Language Specification; the other consists of the CommonLispHyperSpec (also known as CLHS, a densely hyperlinked online version of the Common Lisp ANSI specification) and the online version of GuySteele's "CommonLispTheLanguage", 2nd. edition (also known as CLtL2).

(to those, I'd add GrahamNelson's InformLanguage Designer Manual 4 at <http://www.inform-fiction.org/manual/html/index.html>, which is a joy - I am not overstating - to read)

Response: It's easy for a newbie to find the function he/she wants. But most of the comments ARE out of date. (this comment is out of date - most older / outdated PHP manual comments are being actively purged now. See the documentation mailing list to get a feel of activity: http://marc.theaimsgroup.com/?l=phpdoc. For an explanation of how to read the manual, try here: http://www.sitepoint.com/article/1262/2 )

In general, because the comments are constantly being removed, edited, updated, and folded back into the documentation, the online manual can be anywhere between "Horrible" to "Wonderful" depending on which section you are in, how experimental the extension is, and the phase of the moon.

'Hmm. Phunny, I have been using PHP for a number of server-side applications over the last few years (as of July 2011) and I find the online document support to be generally excellent. Perhaps I just haven't hit upon the foul-documented extension yet. Knock on wood.

A great intro rant about Php:

I can’t even say what’s wrong with PHP, because -— okay. Imagine you have uh, a toolbox. A set of tools. Looks okay, standard stuff in there.

You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes.

You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways.

You pull out the pliers, but they don’t have those serrated surfaces; it’s flat and smooth. That’s less useful, but it still turns bolts well enough, so whatever.

And on you go. Everything in the box is kind of weird and quirky, but maybe not enough to make it completely worthless. And there’s no clear problem with the set as a whole; it still has all the tools.

Now imagine you meet millions of carpenters using this toolbox who tell you "well hey, what’s the problem with these tools? They’re all I’ve ever used and they work fine!" And the carpenters show you the houses they’ve built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door.

That’s what’s wrong with PHP.

http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

A counterpoint antirant:

The programming language many love to hate is experiencing a renaissance. This is not your parents’ PHP. The new PHP is a more mature language with community standards, a growing affinity for interoperable components, and a passionate movement to improve performance. If you have bypassed PHP for alternative languages, or if you are a PHP veteran unaware of recent changes, you owe it to yourself to give PHP a second look.

Language Features

PHP 5.5 (the latest stable build as of this writing) has made major progress from earlier versions. Recent PHP releases contain powerful new features and helpful developer tools, such as a built-in web server, generators for simpler iteration, and namespaces. With PHP 5.4, traits were introduced (a la Scala or Perl) to allow code reuse in single inheritance languages, as well as closures, which allow you to code PHP in a functional style. Other important features include the built-in FastCGI process manager and phpdbg debugger, and a new password hashing API that makes it easy to hash and securely manage passwords in PHP.

http://programming.oreilly.com/2014/03/the-new-php.html

We tend to take for granted features that quietly work relatively well. Our memories work better for "problem" features such that we tend to remember the bad parts but not the good. There are probably many functions and features in Php that do their job without drama that we are not giving Php credit for.

How is PhpLanguage compared to other scripting languages on a WindowsServerTwoThousandThree platform using a SqlServer database? Any articles or forums that discuss this type setup?

That is perhaps too specific a question for this wiki, which tends to focus more on concepts than specific product or product combinations.

See: SuccessHasBattleScars

CategoryPhp