Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

Sebastian Bergmann writes "PHP is a widely-used general-purpose scripting language that is especially suited for Web development. The interpreter that executes programs written in the PHP programming
language has been designed from the ground up to be easily embeddable (for instance into the
Apache Web Server) and extendable. This extensibility is one
of the reasons why PHP became the favourite "glue" of the Web: functionality from existing third-party
libraries (database clients or image manipulation toolkits, for instance) can be made available through
PHP with the ease of use you expect from a scripting language." Read the rest of Sebastian's review.

Extending and Embedding PHP

author

Sara Golemon

pages

448

publisher

SAMS

rating

9

reviewer

Sebastian Bergmann

ISBN

067232704X

summary

The new standard work on extending and embedding PHP.

"Extending and Embedding PHP" by Sara Golemon, a long-time
contributor to the PHP project, remedies the fact that the internals of PHP are far from being as well documented as the rest of PHP. It brings writing extensions for PHP "to the masses", so to speak.

After a short introduction that makes the reader familiar with terms like PHP Extension,
Zend Extension, Userland, and Internals that are used throughout the book,
Chapter 1 ("The PHP Life Cycle") opens with an overview of how the PHP Interpreter
works and what parts (TSRM, Zend Engine, SAPI, "PHP") it comprises.

Chapter 2 ("Variables from the Inside Out") shows how PHP handles and stores variables
internally. The reader learns how to distinguish types, set and retrieve values, as well
as how to work with symbol tables. It is in this chapter that the fundamental unit of
data storage in PHP, the so-called zval (short for Zend Value) is discussed.

Chapter 3 ("Memory Management") builds upon the previous chapter and discusses more
advanced operations on zvals, for instance creating and dealing with copies of a zval or
the destruction of a zval when it is no longer needed. To this extent, the Zend Memory
Manager is discussed as well as underlying principles such as Reference Counting and
Copy-on-Write, for instance.

Chapter 4 ("Setting Up a Build Environment") guides the reader through setting up
an environment, either on *NIX or on Microsoft Windows, for the development and
debugging of PHP and PHP extensions.

After these first four chapters, the reader is ready to go about writing his or
her first PHP extension. Chapter 5 ("Your First Extension") takes the reader
through the steps necessary to write and build a simple working PHP extension.
The following chapters build upon the knowledge gained here, so that the reader
can ultimately implement or change any type of PHP feature.

Chapter 6 ("Returning Values") explains how to pass values (by value, by
reference, and through their parameter stack using references) from internal
(C-level) functions or methods to userland (PHP-level).

Chapter 7 ("Accepting Parameters") deals with the mechanisms involved in
accepting parameters from userland calls to an internal function or method. This
includes the discussion of the zend_parse_parameters() API which makes the
parameters that are passed to the internal function or method as indirect zval
references usable in your C-code. The handling of optional and arbitrary numbers
of parameters is explained as well as the usage of type hinting and its
arg_info API.

Chapter 8 ("Working with Arrays and Hash Tables") explains the Zend Engine's
HashTable API, which is used to store any piece of data of any size, in detail.
Its different data storage mechanisms supported are introduced and compared.
To quote from the book, "A HashTable is a specialized form of a doubly linked
list that adds the speed and efficiency of vectors in the form of lookup
indices". Since these structures are used heavily throughout the Zend Engine
and PHP and its extensions, a good understanding of this API is vital for any
aspiring PHP extension developer.

Chapter 9 ("The Resource Data Type") introduces the reader to the first complex
data type (excluding the Array data type that was discussed in the previous
chapter, which is just a collection containing primitive data types like
strings or numbers). A resource can be, for instance, a connection to a database.
It allows the PHP extension developer to "connect abstract concepts like
opaque pointers from third-party libraries to the easy-to-use userspace scripting
language that makes PHP so powerful".

Chapters 10 ("PHP 4 Objects") and Chapter 11 ("PHP 5 Objects") delve into the
last data type supported by the Zend Engine: objects. Sara Golemon dedicates
one chapter each to the respective APIs of PHP 4 and PHP 5 because of the huge
advancements that were introduced in PHP 5 and that totally changed the APIs.

After the previous chapter, all data types supported by the Zend Engine have
been discussed and the book revisits a topic discussed earlier in the
book: that of the PHP Interpreter's life cycle. Chapter 12 ("Startup, Shutdown,
and a Few Places in Between") explains how to add state to a PHP extension by
using thread-safe globals. Along the way, concepts such as internal and external
(super) globals as well as thread safety are discussed.

Chapter 13 ("INI Settings") shows how a PHP extension can be made ready for
runtime configuration through php.ini settings.

The next three chapters ("Accessing Streams", "Implementing Streams", and
"Diverting the Stream") make the reader familiar with yet another important
API of PHP: the Streams API. All file input/output in PHP userspace is processed through PHP's
Streams Layer. This layer, that was introduced in PHP 4.3, is what
makes working with files, compressed files, and remote files, for instance,
seamlessly in PHP. The reader learns how to work with streams as well as how to
expose streamable resources, whether remote network input/output or local data
sources, using the Streams API, thus avoiding the need to reimplement all the
tedious bits and pieces that are normally associated with this.

Chapter 17 ("Configuration and Linking") builds upon the tools and techniques
introduced in Chapter 4 and adds the GNU autotools (autoconf, automake, and
friends) to the reader's set of tools. These tools, if used correctly, allow
the extension to be built in environments that the extension author does not
know or has no access to.

Chapter 18 ("Extension Generators") takes a look at ext_skel (which comes with
the source distribution of PHP) and PECL_Gen (which can be obtained, as the name
suggests, from PECL, the PHP Extension Community Library). These two tools
automate most of the steps described in the previous chapter and take a lot of
tedious work out of the extension writer's hands.

Starting with simple embedding examples, the reader learns in Chapter 19
("Setting Up a Host Environment") and Chapter 20 ("Advanced Embedding") how the
PHP Interpreter can be embedded into almost any other application.

The book concludes with the "Zend API Reference", "PHP API Reference",
"Extending and Embedding Cookbook", and "Additional Resources" appendixes. The
first two are a great resource for both novice and experienced PHP extension
writers (even for people working on PHP and the Zend Engine itself). The third
features a collection of common use code snippets while the last one points the
reader into the direction of PECL by suggesting a couple of existing extensions
to look at and learn from.

Since the topic of this book is to extend the PHP Interpreter using extensions written in the
C programming language (or to embed it into an application that is written in C), a good
understanding of C syntax, its datatypes, and pointer management is important to get the most
out of this book.

Being a contributor to the PHP project for about six years now, I have been looking forward to
this book. True, there is always the source code of the PHP Interpreter as a source of information
on how "things work". But although being the ultimate reference, reading the source code cannot
replace a thoughtfully structured and well written guide that gets you started. If you are looking
for such a guide, look no further: you will find it in this excellent book.

Although it deals with a very technical topic, "Extending and Embedding PHP" is readable
and the many code examples are easy to follow. The reader profits from the knowledge
of the author, who has been involved in the PHP project as a core developer for over
four years now and is also the author and maintainer of a dozen PHP extensions that are
available through PECL. The book covers both major versions of PHP that are currently
used, PHP 4 and PHP 5, and it will continue to serve its purpose when PHP 6 comes out
next year.

The book sounds interesting. There's also an often-overlooked capability of PHP: the ability to use php-embed [php.net] to run embedded PHP within a C/C++ app. For example, our company created an HL7 accelerator--we chose PHP as the embedded language in our product--by which users can more easily create custom data transformations.

The reason? PHP is easy to use, loosely-typed (which happened to be an advantage in this case), fast, and of course the license works. It was a great decision.

PHP-embed is basically just a TSRMLS function wrapper. It's pretty straightforward; for example, zval integration is easy as pie, as I recall, something like:

Yes, really... an informative and helpful FP getting modded down. Oh wait... this is Slashdot. It was modded down because the canonical form of a first post is in fact an off-topic rant, or some stupid pun on the story title.

You bastard. You said the evil word and now I can't sleep for 7 days and 7 nights.

Aaaah.... it brings back fond memories of weeks-long being swamped by specs, hundreds upon hundreds of pages of specs. And when you thought you 'got it', some idiot brought out a new document with rather creative new uses of that same spec. I love this HL7 v2/v3 standard shit!

Ok, so 5 of the first 7 comments were trolling about how bad PHP is, insecure, buggy, etc (and I think they even managed to take a shot at Bush???)

I've used PHP for some very small applications/sites. Can anyone give an unbiased (almost impossible I know) state of affairs for PHP? I know that it is a pretty common tool, has its strengths and weaknesses. However, is it really that bad or is bashing it just the current/. thing to do?

A lot of people who bash PHP are perl zealots or come from a strictly typed language like C and see loosely-typed code and lazy and ugly. Being loosely-typed makes it easy to use and as a result, the layperson can pick it up and write scripts. Of course, anyone doing professional work will looks at these scripts and their vulnerabilities and scoff at it, but they fail to realize that a lot of PHP that is floating around is not written by professionals. It is not a fault of PHP but the people who use it.

However, is it really that bad or is bashing it just the current/. thing to do?

I think PHP has replaced Java as the favorite "kick the dog" language on Slashdot. IMHO, PHP is no different than any other language. It takes work to write consistently clear code that other people can understand.

I was referring to the writing of source code. Not the pecularities of the language itself. If people can't read your source code, it doesn't matter that the langauge itself sucks. Of course, it's easy for a lazy programmer to blame the language instead of cleaning up the source code to make it readable.

If people can't read your source code, it doesn't matter that the langauge itself sucks. Of course, it's easy for a lazy programmer to blame the language instead of cleaning up the source code to make it readable.

I couldn't have said it better myself. I personally use PHP for many small applications. I also make sure to heavily comment my code, and I try not to obfuscate my code (it kills me that some people compete to see who can write the most obfuscated Perl, for example. Try interpreting or revising that code a year from now).

Many times I've had to revisit code years after having written it, and when there are no comments, it is difficult to see what exactly I was thinking at the time -- in *any* language. Non-descriptive variable names, or attempting to put as much code in as few lines possible, are, IMHO, bad practices.

Personally I see nothing inherently wrong with PHP. If I'm working with a web-based application, under Apache, using a MySQL database, PHP is the first thing that comes to mind. Image manipulation (now integrated) and HTTP features (headers, cookies, form data, file uploads, etc) make PHP an easy choice for many web applications. I've done all of this in Perl, and some in plain-old-C, but PHP makes these things so easy...

Of course it's not for everything. I try to use whatever platform/language is most appropriate for the application at hand. Sometimes it's C or C++, perhaps it's Perl, whatever - I use whatever makes the most sense for what I'm hoping to accomplish. It just happens that, on my Linux server, PHP often stands out as the best choice. When writing Windows applications, I use a hybrid of VB6 and (in the form of a back-end DLL library) C/C++. On the server, PHP most often comes out as the clear choice. Ease of use, abundance of built-in functions/features, ease of database-to-web integration, and relative security all make PHP a good choice for many of my projects and ideas.

Some have referred to PHP as "loose", and I admit sometimes it can be. There is no equivalent to Perl's "use strict", and it's easy to unintentionally leave an opportunity for a user to pass unexpected variables -- but as long as you are able to keep this in mind, it's not difficult to make a relatively secure PHP script. Just make sure any important variables are declared/set/validated at the start of the script. I admit, I do love Perl's "strict" module, since it leaves no question as to whether a variable's data is trustworthy... but PHP is a different language, with different features. You can't discount it as a viable language because of a single missing feature...

Some have referred to PHP as "loose", and I admit sometimes it can be. There is no equivalent to Perl's "use strict", and it's easy to unintentionally leave an opportunity for a user to pass unexpected variables -- but as long as you are able to keep this in mind, it's not difficult to make a relatively secure PHP script. Just make sure any important variables are declared/set/validated at the start of the script.

Err... error_reporting(E_ALL|E_STRICT); is what you're looking for. It warns on uninitialised

If you know about its flaws (Lousy SQL handling and register_globals foremost among them), it's fine. No real security problems.The problem (The reason it's got a reputation for bad security) is that many users don't know about these problems, so they don't write secure code. Stuff like:$user=$_GET["u"];$res=mysql_query("select data from users where userid=$user;");

(It's a SQL injection waiting to happen, what if I load this page with u="0;drop table users;"?)The rapid uptake of PHP among new programmers is

(It's a SQL injection waiting to happen, what if I load this page with u="0;drop table users;"?)

Well, one would hope that the READ access you've given to the user you're connecting to the SQL DB with doesn't have the ability to run DROP TABLE.

It's about access control too.

I mean I agree with you on the fact that SQL injection attacks are easier in PHP, but lets face it, you can also design any language to be vunerable. PHP just makes it a little easier by not requiring some sort of connection lib

Your example is slightly flawed as mysql_query doesn't allow the execution of multiple sql queries by default. And if you enable it for some reason, then chances are you think you know what you are doing.

But things like SQL Injection is one of many reasons I just love ASP.NET.

I wrote a very short piece [kjonigsen.net] on this on my site, and how use of paramertized queries/stored procedures in 99% of the cases eliminate this problem entirely.

It also includes a comprehensive SQL Injection demonstration, which I'd recommend that everyone working with DBs should read. Using PHP/Perl/ASP.NET or whatever their favorite web-programming lanaguge happen to be.

But things like SQL Injection is one of many reasons I just love ASP.NET.

I noticed that the server in question is actually a Windows box running MS SQL. Not that this means anything by itself, but personally I consider Windows to be a desktop OS, and personally I would never rely on Windows in a server environment. But opinions aside...

I admit, the code you exploited could have just as easily been PHP on a *nix platform, so I cannot blame the operating system. I can only blame the programmer that left this

and personally I would never rely on Windows in a server environment. But opinions aside...

I wouldn't consider any server more secure then the admin actually running the machine. A competent windows admin will more than likely have a more secure setup than a incompetent Linux admin. But, as you said, OS-related stuff aside.

I admit, the code you exploited could have just as easily been PHP on a *nix platform, so I cannot blame the operating system. I can only blame the programmer that left this gapi

For those who may be curious, the proper way to actually prevent SQL injections is to wrap anything coming in with a function that calls stripslashes() and mysql_escape_string() (or equivalent function for another db). For example, the function I use looks like the following (this also adds quotes around anything that is not numeric):

Now this is perfectly safe from SQL injection. Anyone who has done real web programming knows all about this and knows that you need to deal with this sort of thing regardless of what language you're using.

Also, whenever you emit data that will appear in HTML you also need to wrap it. This time you just use the builtin htmlentities() function like:

This prevents cross site scripting. Again, no different from any other language.

PS: IMHO if someone goes out of their way to claim something "sucks" they probably don't know what they're talking about. Try the other languages and read the documentation so that you can evaluate which is best for your project.

"Now this is perfectly safe from SQL injection. Anyone who has done real web programming knows all about this and knows that you need to deal with this sort of thing regardless of what language you're using."

Point taken, in that a lot of web scripting languages you have to be careful with SQL injection - but careful with your statement, I do 'real web programming' and do not have to worry about this per say, as I am using a full MVC framework (struts). If you are truely seperating the 'V' from the 'M' a

Fortunately, the Zend Framework will soon come to the rescue. In the meantime, I have written my own PHP DAL. It felt like reinventing the wheel, but my other options at the time were all unstandardized frameworks that were either too restrictive or just poorly written.

RoR is looking more and more attractive. I'm currently considering porting the next version of the application for which I made my own framework.

For those who may be curious, the proper way to actually prevent SQL injections...

I'm not negating your point, as I do agree with it. But it can be put much more simply: a script should NEVER trust ANY user input, period. Anything passed to the script should be validated; make sure a value is within range, or otherwise is an expected input. If the input doesn't match some predefined pattern, it should be rejected.

I do love PHP, and I use it quite frequently, but Perl has the "scrict" module that I personall

You're absolutely right -- I confused the two because I used to use both, and it's been about three years since I've done any serious Perl coding. Taint mode (all external data is considered "tainted") helped to ensure that you at least looked at/modified outside data, before you used it. Otherwise, an error was raised.

Strict would have been (if I remember) the module that required you to declare all variables/functions/references. Again,

Or you could just use prepared statements, then you really are protected, even when a vulnerability is found [slashdot.org] in your ad-hoc method for "escaping" strings. Really, is it that hard people?

Come on, people! You do not escape your own values, because you'll inevitably forget something. Instead, you use parameter substitution and let the language do the work for you. If some new vulnerability comes along, would you honestly rather re-write every database access module you own instead of just upgrading the language's core library and being done with it?

Is it just Firefox on Linux or does that code formatting look bad for anyone else? The code is double spaced. What happened to simple pre style? I would think with all the programmers on./ that more people would care about how code formatting looks.

Also, regarding sprintf, if your query has 5 parameters using sprintf is a lot easier and it's probably more efficient.

Some people also use a function to strip out less than/greater than signs from data (or simply use htmlspecialchars/htmlentities) before adding it to a database. Their desire is to prevent cross-site scripting attacks. This is a lazy hack. A better way to combat cross-site scripting is to apply htmlentities to data being pulled out of the database for display. If you are using "real" W3C DOM scripting methods and not innerHTML, you can simply add the data as-is (making sure your JSON methods slash out any w

Why does this nit always come up? Sincere question, I assure you: pretty much *every book or tutorial on PHP has "Turn Off register_globals" in the first chapter." And it's off-by-default in the last few major versions. I remember some popular (but crummy) big apps like osCommerce required(d?) it and when I discovered that (in 2003!) I about fell out of my chair.
And in agreement with another poster, SQL injection is basically-impossible in any language when you set up your privs intelligently.

It's a language used by a lot of beginners, so you see a lot of beginner code written in PHP.

It's historically had some really poor design decisions that have led people into making grave mistakes.

There are a number of better options available that people tend not to use because PHP has greater mindshare and therefore more hosting companies make it available. By comparison to the better options, PHP is crap.

Granted, I've worked with PHP and therefore I don't like it. But that was 4 years ago or so. Maybe things have changed.
But I do think parent poster has multiple points, and simply mod'ing him Flamebait since PHP is your favorite scripting language won't change that.

Saying that beginners PHP-code is ugly is more a statement of facts than an opinion.

Mod parent down, preferably Troll. Of all posts up to this (parent one), PHP is only mentioned once in what one might say a negative way (it asks about a PHP security book, doesn't directly imply anything about php). The only post about bush says something like "slashdot sucks with all the ani-bush articles".

It's pretty bad. To begin with there's therandom() naming_scheme(). On top of that there's the lack of namespace support, so we have str_pad and strlen rather than something like:

use str;$res = pad($var, len($string), ' ');

The devs should add namespaces and camelCase all function names (Currently function names are case insensitive). They could even have a secondary function table with aliases for backwards compatability, since simple sed commands or search and replace are apparently too esoteric for th

Absolutely. More than anything else, these are exactly the things that are driving me away from PHP. magic_quotes* issues can be coded around (though they shouldn't have to be), but when I have to keep php.net open all the time to make sure a function is still called what I think it should be (often I'm still wrong by an underscore), I'm not a happy developer.

It seems that anything that takes off and allows beginners to gain traction quickly is beaten down by the purist. Windows is beaten down because "only an idiot would need a GUI" - it's that type of attitude that hates PHP or anything else that's more about being productive than being about the technology.Personally I've been programming in both the *nix and Win* environment for 10 years. I find PHP a fast, fun, language that allows me to build solid (mostly web) apps quickly. The language constructs "jus

PHP has a lot of little language quirks that can bite you on the ass pretty regularly while you climb the learning curve. It's easier to get started writing bad PHP code, then distribute it to a mass audience, than just about any other web scripting language. Those two things are responsible for 99% of the bad blood towards it. From me it gets some bonus points in the hate column for basically turning into Java with dynamic typing in PHP5, but I'm pretty anti-Java, and I guess other people like that.About 7

I've just started a decent sized coding project in PHP, and since I'm well aware that it's easy to write Swiss cheese-code, I figured I'd just pick up a book on PHP security. Two actually. They explain how to fix or avoid the stupid problems that unsuspecting n00bs tend to make (and, indeed, I would have), and write code that doesn't require register_globals to be enabled and guards against those ubiquitous SQL injection attacks. Money well spent.Are there quirks? Certainly. I've had a couple functions

5 of the first 7 comments were trolling about how bad PHP is, insecure, buggy, etc

That's because there are people who are trying to reinvent a 40+ years old language who do not like the way PHP has taken over the web. They simply hate the way sites with page names ending in ".php" outnumber sites with pages names ending in ".rb".

Those people are too stupid to understand Lisp, too ignorant to know the good points of Lisp, and too close-minded to try learning how to use Lisp, therefore they tried to create a

This is a poor excuse for a stab at Ruby. Most Rubyist sites tend to be powered by RoR, which in part explains why you haven't seen many ".rb" pages around. Also, how would Rubyists complain about PHP "taking over" the web (implying this should be the "domain" [pun] of Ruby powered sites) when so few of them were introduced to Ruby before 2000? Though PHP and Ruby were introduced around the same time, it took Ruby slightly longer to reach an English-speaki

if it does what you need, then it's a good tool. for you.
if it can help speed a project along, then it's a good tool. for that project,
if it's stregth's fit with your needs, then it's a good choice.
it it's weaknesses aren't neceassrily a problem, then it's a good choice.
you wouldn't write a kernel in java or python, and likewise you wouldn't write a log file parser in C. there's a reason why millions of web sites out there are based on LAMP. and it isn't because they're "free". a good programmer wr

The PHP Function List [php.net] gives 4,834 functions in the main namespace. The problem is that rather than start with a small set of orthogonal primitives and build upon them, they've added a new function for each and every possible operation anyone would ever want to perform.

For example, PHP has a special function to see if a given key is in an array:

array_key_exists('key', myarray)

In Python, you'd use the standard syntax for determining if a value is present in any list-like object

There have been some very useful comments, but that very succinctly got your point across (as to your dislike).

So I have to ask, what are your feelings on perl? It has several ways to achieve the same thing. However, at the same time you could know a small subset very well and be able to acomplish most any task?

My current job doesn't really require me to do that much scriping, but when it does, I usually go to perl. I've never used python although it seems to be a good alternative. Also, even though

I like Perl and used to use it a lot, but I've replaced it with Python for personal and business use. I don't have anything against it; it just wasn't as close a fit to the way I think about programming.

My current job doesn't really require me to do that much scriping, but when it does, I usually go to perl. I've never used python although it seems to be a good alternative.

We use Python for full-blown application development and have been very pleased with the results. If you're interested in trying i

I'll check the book out. I have been frustrated in the past with languages (ColdFusion for a project at school, assembly..., and other nuances of different languages), but all in all I don't guess I've ever really come to love/hate a language. I especially haven't liked a language enough to have to "defend" it.

...if only to make you appreciate how much you like the others you already know

Exactly.

While I do understand that different languages have strengths and weaknesses. At least with the type of pro

If you're interested in this, you'll probably be interested to know about Ian Bicking's work on embedding PHP in Python web applications [ianbicking.org] via PHP's FastCGI support. It's only in the experimental stages, but it's very promising, especially for developers like me who develop with Python but need to support legacy PHP code.

Yeah, so PHP stands for "Personal Home Pages" but that's is an historical misnomer now. PHP has a CLI binary that can be used to run scripts on the commandline. Obligatory "hello world" follows:

!#/usr/bin/php
echo "Hello, world!";

Now consider that PHP ships standard on virtually every Linux distro and comes with a large assortment of libraries. You can write LDAP scripts, do IMAP, generate images, the list is loooong. It amazes me that PHP isn't used more in corporate envirments. PHP is easy to use, arrays are surprisingly useful, and you can do a little OO (which is just the right amount IMO). And something that a lot of people take for granted is that the documentation on php.net is great. Everything is on one place unlike other languages (e.g. Python) where you just get redirected to every little sourceforge scribble and wiki there is.

I'm a C person. I'll continue to use C for heavy lifting but you also need a good scripting language. I just wrote a Zend extension to interface with some of my C work and it exceeded all of my expectations.

If you're looking for the lastest hot new "technology" then Ruby is a good buzzword. Otherwise, if you're just looking to get work done, so you can go home and play with your kids, PHP is a workhorse.

PS: I don't know spit about this book but the tutorial on writing extensions on the Zend website was pretty good. Good enough for me anyway.

Yes, when you think about all the capabilitise you get in such a small package, it puts most large application libraries like Java to shame.

I use PHP extensively as a Unix scripting language. It performs quite well, even running a collection of scripts for an extended time as a daemon. You might be surprised how efficient PHP is at handling very large arrays running in memory.

And yes, it is a workhorse. It may have a few oddities and rough edges, but mostly it just stays out of the way and lets you work.

Is this a troll? I just can't tell what's a joke and what's serious anymore. PHP fans and haters are far too ambiguous...I'm a PHP developer but I also write Perl and C as part of my daily job. I use PHP for all my web development, anything that has a web front end will undoubtedly be written in PHP though I have done Perl and C for web (I still hate cgi). Perl I use mainly for sysadmin type applications, easy way to automate my tasks when they're more complex than a simple BASH script will do (database con

I'm a C person. I'll continue to use C for heavy lifting but you also need a good scripting language. I just wrote a Zend extension to interface with some of my C work and it exceeded all of my expectations.If you're looking for the lastest hot new "technology" then Ruby is a good buzzword. Otherwise, if you're just looking to get work done, so you can go home and play with your kids, PHP is a workhorse.

No, it isn't.

Sorry, but this post sounds very blinkered. You are ignoring the 'elephant in the room'. T

Eh... PHP isn't exactly installed as widely as Perl, Python or even Ruby on non-web-server machines. And I usually see PHP just installed as Apache mod_php rather than the CGI interpreter.

Also, I'm kind of divided on whether the "everything in one place" is actually true. PHP can be compiled with different modules. So can other scripting languages, actually. Installing the stuff that's missing from your site's particular bit is either surprisingly simple if you're root (apt-get install php5-whatever) or s

A lot of PHP bashing going on; I'd just like to chip in my 2 cents on the language (and demonstrate a mild interest in the book).
I was big on programming when I was younger - by 14 I had written an adventure game in Basic and I invented a DOS-based graphical application that is eerily similar to Flash (two stickmen and some props on the screen with keyframes and interpolation tracking). Needless to say I was well advanced of my classmates throughout highschool.
I also wrote a Chess AI (who hasn't?) in C.
But that was the end of it - about 10 years ago now. I longed for programming but Real Life(tm) got in the way and other career paths curbed my free time.
Needless to say I had lost a lot of skills and I don't even know what OOP stands for, but getting into the blogging world and creating a custom website to house it resulted in me having to learn some sort of web-based programming. I have to say that PHP was beautifully easy to (re-)learn and I was back in the programming seat with a big grin on my face with just a few weeks of self-learning (by looking at examples and open source, no books). I'm praising PHP as a very easy to learn, easy to use starting point for all my would-be programming friends.

Wow. That'd have been the story of my adolescence to the letter, if my otherwise fine secondary school hadn't been an IT wasteland. I got a start in BASIC back in primary school, and was eager to take it further when I moved on. The first chance I got, I logged in and opened the first recognisable name I could see: Visual Basic.

You there! Did I tell you you could run that? No? Well then close it!

And thus endeth my programming career until the lazy days of university some eight years later.

Many people just use PHP because it's popular and because they can't be bothered to use anything else. Which is a shame, because it doesn't deserve to be, and many people should be much better than that.I remember when I picked up PHP. It was brilliant. Look at me, I can create dynamic web pages! I could do for loops, and while loops, and print out numbers without using JavaScript! And now, I can take parameters in from $_GET[], and make a proper website in only one file!:D! I got a website with Tripod (ur

I think that there is a contingent of web programmers that are bored and upset that PHP is still the premier method for scripting websites. They want something new and fresh to work with. I can appreciate that. When you use the same language for a long time, it starts to look "old". This is exacerbated when they inherit sloppy code and are forced to decipher and fix some other dummy's spaghetti. So they declare the language "dead" in hope of creating enough spin and FUD that something new will take over. Something new that will create work and give them more job opportunities. The same something new that they invested a lot of time into learning.

To the PHP bashers - you might succeed in selling something new but after the next guy inherits your spaghetti code they will start bashing *you*.

Don't be fooled people. Every language has it's corners. I spend 90% of my time doing C but I just spent a month doing a standard LAMP site and I just don't see what these guys are hee'n and haw'n about. PHP is just as useful today as it was on 1998 so I'm willing to bet it will be around for a long time still. Don't be influenced by some bored guy saying "it sucks" and "I hate it". That's just not intelligent criticism. Try different things and make up your own mind.

PHP has a huge install base and has served us very well for many years. Let's not forget that. The PHP bashers pushing Python and Ruby should be ashamed of themselves. Post some useful information about how Python or Ruby solves a problem you think PHP has. And no cryptic one liners thank you. Get a spine and post some useful comments.

I'm in a small build team going through major evolutions with our software. We got to the point where we are using at least 7 different languages - C, Perl, JSP, Java, bash, BAT files, XSLT, PHP plus the usual markup languages (home-grown XML, HTML) and SQL. We went through one rev to try and go to Java (using JBOSS with it's JMS implementation, plus JSP etc), we came to the conclusion that, for a small team, it's just too big a cost in development time. We decided on Python in the end, as it covers all our

You know, other languages have libraries and modules, too...PHP isn't the first language with MySQL bindings. It's not the first with GD bindings. And so on.And PHP wasn't really designed to be easy to properly embed in other applications either. It was designed to have the code embedded in HTML, granted. And it was designed to run in the web server. But I doubt it was designed to be put to all kinds of use. Who is embedding PHP except for web servers?If you want a language that was really designed for embe