Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

Zend in the clowns?

By serious articles in Op-Ed
Thu Jul 15, 2004 at 06:29:33 AM EST
Tags: Software (all tags)

PHP has gone from strength to strength over recent years.

Reputable sources have demonstrated both its phenomenal growth rate, and indicated that it is the most-used Apache module by quite some way, flooring even the twin titans of mod_perl and OpenSSL in the popularity stakes (a fact which some people seem quite keen to gloat about) [1].

Tiobe Software's "Programming Community Index" (a nominal measure of the popularity of programming languages and skillsets) ranks PHP as having climbed so far as to be tussling with Visual Basic over fourth position, only being clearly bettered by the heavyweights of C, C++ and Java. Along with Perl, Apache, GCC and the Linux kernel, it is one of the undisputed heavyweight success stories of Free / Open Source Software.

On Tuesday, PHP v.5.0 was finally unleashed upon the world. What is starkly evident is that, whilst the developers have spilled blood to facilitate backwards compatibility, enormous changes have been made, both to the language syntax and its capability. These changes have implications beyond the world of PHP itself: They are representative of a certain trend in programming languages and the advance of technology in general.

So do these changes Promote Hyper-productive Programming, or are they just Purloining Heinous Piss ? [2]

A Potted History of PHP

PHP began life in 1995 as little more than a series of perl scripts developed by the cheesily-begrinned Rasmus Lerdorf. Originally entitled 'Personal Home Page tools', they were predominantly used to track usage of his website and ease certain maintenance tasks. Interest in them grew and he reimplemented them directly in C, including such useful features as database connectivity and primitive dynamic content manipulation. This was subsequently released as PHP/FI ('Personal Home Page / Forms Interpreter').

In 1997, two students (Andi Gutmans and Zeev Suraski), rewrote much of what was then PHP/FI v2.0 to aid in the construction of an eCommerce site they were developing at university. This resulted in PHP v3.0, which is the beginning of the PHP we see in use today, with the Gutmans and Suraski engine at the centre of a coagulated, custom-modified collection of other libraries (predominantly C-based). Version 3.0 also heralded something of a rebranding exercise, with the letters PHP now standing, in inimitable unix-hacker style, for the compulsory recursive acronym "PHP Hypertext Preprocessor" which, the recursive element aside, is a far more accurate description of its v3.0 and v4.0 usage. Version 4.0 was the result of a rewrite of the core engine (now called the Zend engine - Zeev Suraski, Andi Gutmans) to enable even more breadth of use.

Zend is also the name of the resulting business established by Gutmans and Suraski, and Zend contributes engine development to the evolution of PHP, whilst selling proprietary database and optimization enhancements to paying customers. Meanwhile, the usual crew of disparate coders add other enhancements and library extensions. Hitherto, the saga has been a notable success in the blending of open source development and corporate interests. [3]

For PHP v5.0, Zend have done a second ground-up rewrite of the engine to allow for the swathe of new features; the new engine being the Zend engine v2.0. One observation of the new feature set is that they may need to 'rebrand' yet again: It is patently obvious that "Hypertext Preprocessing" is not solely what the latest modifications are geared towards.


A Pretty High-level Perspective of the Older Syntax (PHP v4)

The syntax of PHP looks like the offspring of a drunken alley-fondle between C and Perl. Given its heritage, this is hardly surprising. It is also another reason for its phenomenal popularity. Perl coders wouldn't dream of using anything else on a web server, but programmers familiar with any C-like language, and a basic understanding of HTML, HTTP and CGI, can get up to high speed with PHP very quickly, often in less than a day (feel free to make your own jokes about dealing with "write-only line noise" at this juncture)[4].

PHP was originally developed to be intermingled with HTML so it is encased in tags, much like ASP. To break into PHP the <?php tag is used and its sibling ?> tag is used to break back out. There is a short form of the opening tag ( <? ) which can be used if specified in the 'php.ini' configuration file. Likewise, ASP-style tags (<% and %>) can be used if configured similarly. If a lot of work with XML is being done, these alternatives may have to be used creatively to prevent certain kinds of parse error, although this often isn't a problem.

Comments can be either multi-line C-style (/* ... */), single-line Unix/Perl-style (# ...) or single-line C++-style (// ...) [5]. Like C, statements in PHP must be semi-colon-terminated (';') unless they occur immediately before the closing PHP tag, as this will automatically terminate the statement successfully.

Variables are weakly-typed and begin, scalar-perl-style, with the dollar-symbol, like so: $hello.

Basic integral values (0, 1, -255, 32768 etc.) are implemented behind the scenes as signed longs; Floating-point types (3133.7, -0.001, 3.141592 etc.) are implemented as doubles; Strings are implemented as custom-written structures; Everything else (objects, arrays etc.) is implemented using hash tables (aka. maps) [6]. All of this is transparent to the programmer and no knowledge of the underlying implementation is necessary to use the language itself. Variables inside double-quoted strings ("$x") will be expanded; those inside single-quoted ones ('$x') won't. The dot/period/full-stop character ('.') is used for concatenation.

This set-up has a number of advantages, including allowing for simple multi-dimensional arrays and type-agnostic array-storage. Arrays must be declared with either the array() function call, which provides an interface for both simple (value only) and complex (key and value - i.e. mapping) declarations, or using the traditional syntax with no call to array() necessary. In the latter case, if the specified key is not present it will be created, otherwise it will be over-written. For example:

$anInteger = 54321;
$aString = "Monkeys";
$compoundString = 'This is ' . 'a compou' . "nd string showing a monkey count. $aString : $anInteger";

$anObject = new TokenObject; // declared elsewhere...
$integerArray = array(5,4,3,2,1);
$stringArray = array("Just say no", "to", "working", "today");

$anotherIntegerArray = array(0 => 0, 1 => 1, 2 => 2, 3 => 3);
$integerMap = array("zero" => 0, "one" => 1, "two" => 2, "three" => 3);
$stringMap = array("Barcelona" => "Europe", "Seattle" => "North America", "Jaipur" => "India", "Washington" => "Another Planet");

$tradSyntax[0] = 99;
$tradSyntax[1] = "bottles";
$tradSyntax[2] = "of";
$tradSyntax[3] = "beer";
$tradSyntax['alternatives'] = array("urine", "peroxide");

$sillyDataStructure = array(
    $anInteger, $aString, $compoundString, $anObject,
    $integerArray, $stringArray, $anotherIntegerArray, $integerMap,
     $stringMap, $tradSyntax

There are the usual cast of control-flow statements and operators, including a fully-working switch-case construct and bitwise manipulators. To get around some of the issues raised by using weak data typing in combination with C-based syntax and libraries, PHP introduces two new operators: "===" and "!==". These are equivalent to the standard equality operators ("==" and "!="), except that they take the underlying type of the variable into account. For example:

$someVar = 0;
if($someVar == false){ // ... TRUE - same binary value...
    if($someVar === false){ // ... FALSE - testing against a boolean, but the variable is an integer...
        // won't get here ...

These come in useful when using functions like strpos(), which will return false in the instance where the sought string is not found, but 0 in the instance where it is found at the very beginning of the string (offset 0). If tests using the normal equality operators were performed, it would be very easy to get the wrong impression.

The default behaviour of PHP is to let everything "fall through" to the default handler routines of the environment (most often Apache), except for content encased in the tags, which is parsed and executed via the engine. This feature can be 'abused' for structural or optimization purposes. As a very simple example:

    // Some PHP code here ...

        // string is burped out by PHP ...
        echo('<p>someVar <i>is</i> set.</p>');
        // break out of PHP...
        <!-- We're "in" Apache here - normal spit-out of HTML -->
        <p>someVar <i>is not</i> set.</p>

        <!-- Break back in to PHP -->

Functions are defined (not surprisingly) with the function keyword. By default, arguments are passed by value, although there is a similar syntax to C/C++ for passing by reference. C++-style "default arguments" are also featured. For readers unfamiliar with these: They are a way of stating a function's argument list so that, if the funtion is called with fewer than the declared number of arguments, the default is selected. It is a way of avoiding / improving on function overloading (which is supported in C++, Java and the new PHP v.5, but not PHP v.4). For example:

function insult($name = "Bob", $phrase = "Screw You"){
    echo($phrase . " " . $name . "!\n");

Called without arguments, insult(); would print:

Screw You Bob!

Called like this:


The following would be printed:

Screw You uid:3!

But, if called like this:

insult($anArbitraryDislike, "The zenith of the art of pig-humping has been achieved by");

Well, the output is fairly obvious...

There is an enormous, fully-developed standard API of functions for myriad purposes. C programmers will recognize many of the function calls and libraries involved due to the fact that extending PHP requires little more than specifying some custom headers (which export the library interface and act as intermediaries between the native C library and the Zend API), defining the function implementation within the bounds of the engine's thread-safe resource manager and then compiling accordingly.

Some functionality requires an external library to be present on the system, but PHP ships with 'versions' of many of these libraries built-in. On Unix systems, deciding what to include and what to exclude can often result in a ./configure statement of ten lines or more in length, and it's well worth saving it to a text file for future use when you've got it how you want it. On Microsoft Windows systems, these modules tend to ship as pre-built binary DLLs whose inclusion is achieved by uncommenting certain lines in the aforementioned 'php.ini' file. Similar modularization can be achieved on Unix systems, but most people statically compile the requested libraries directly into PHP (and some then statically compile PHP directly into Apache).


Providing Helpful Prerequisites - a quick deviation / crash-course about Object Orientation (OO)

For readers unfamiliar with object-orientation, the basic idea is that sequenced, procedural function calls are replaced by encapsulating most of your code into objects (classes). Objects contain their 'own' variables and functions (members). These objects can then be used, or 'hooked-up' with other objects, and use their own members to 'communicate' with each other.

On its own, this mechanism would offer only a slender syntactical advantage over encapsulated structural aggregations containing variables and function pointers (e.g. structs in C); and the very slight overhead involved in constructing the objects may cancel that advantage out. If it were just about code organization, object-orientation would be useful, but more than a little underwhelming (of course, the true hardcore proceduralists consider it so anyway). The main power of object orientation, however, comes through a concept called polymorphism.

Polymorphism relies on the idea of class hierarchies. For example; imagine a base class (an object at the top of the hierarchy) called Idiot. There could then be sub-classes (derived objects) of Idiot called InternetIdiot and Politician. InternetIdiot could, in turn, have sub-classes called Troll, Biter, LongScreedWriter etc. The key idea here, is that sub-classes inherit member variables and functions from their super-classes, but have the option of over-riding the members they inherit with implementations (function definitions) which are custom-designed to suit the purpose of the given object better.

Imagine Idiot has a member function called saySomethingStupid(), which causes the phrase "I am an Idiot." to be printed out.

InternetIdiot might then over-ride this function to print out "I am teh Lam3r!". In turn, Troll might over-ride this function to print out "-1, I just had an uncomfortable pooh!" instead, whereas Biter might over-ride this function to print out "You are wrong and I am right." etc. [7]

Let's say we write a function to take an Idiot as an argument. As an example (Using C++ in this specific instance):

void speech(Idiot* i){

What polymorphism means is that you can pass a pointer to any type of Idiot (an Idiot , or any of its sub-classes) into this function and the correct version of saySomethingStupid() will be called automatically for that particular kind of object. The function doesn't need to know the exact type of the argument; all it needs to know is that it's a kind of Idiot; polymorphism takes care of the rest. Part of the idea is to replace the endless chains of if-else and switch-case statements that pepper much procedural code by having the correct behaviour called at the point of use.

As ever, there are many variations, tricks and implementation details that complicate this idea, but that, in a nutshell, is what object-orientation is all about. Many programmers use object-orientation all of the time without even realizing it. Using some libraries, when you create an instance of, for example, a GUIWindow, it may itself be derived from a generalized GUIFrame object, which is in turn derived from an abstract GUIComponent. Part of the beauty of this mechanism is that the programmer doesn't necessarily need to know, but if they want to they can extend components themselves to add more options.

PHP v4 contains classes, primitive constructors, member variables and functions, basic polymorphism and primitive support for initialization. A full description would be far too large to entertain here but, seeing as most of the new features of PHP v.5 radically extend this functionality, and the object model has been completely rewritten from scratch for PHP v.5 (Zend Engine v.2), we'll do a quick drive-by in the next section. [8]


PHP Hits Puberty: The Next Generation (v5)

This section is intentionally terse, with fairly little explanation of the terms involved, as object-orientation is a massive subject; a behemoth; some would say a mess, and none of us want to be here all week (see Author's Comment).

Reading this, some programmers may well begin to surmise that Perl and C were not alone in that alley the night PHP was conceived; it seems to have been more of a threesome.

So what's new?

  • Objects are now passed by 'handle' - This is a fancy way of saying that, in essence, they are passed by reference and not value.

  • Object Cloning - this is implemented by the clone keyword. As soon as PHP v.5 decided to start passing objects by reference as a default, it had to implement some form of copy-constructor mechanism for those times when a programmer actually wanted a duplicate and not just another reference to the same object: This is it. Each object wishing to over-ride the default assignment semantics must implement a __clone() function. When the following occurs:

    $monkey = new Character();
    $pigsy = clone $monkey;

    's __clone() function is called to produce a correct $pigsy. What counts as 'correct' depends on the context. A default __clone() function is applied by the system; once a programmer over-rides this function, they must take care of all the initialization for that object themselves.

  • The instanceof keyword / operator - With vastly increased object-orientation capability, some form of cheap and cheerful run-time type identification was needed - this is it. It is similar to a simplified version of the typeid operator in C++.

  • Reflection API - Reflection is a way of probing, examining and reverse-engineering classes, interfaces, functions as well as extensions, on the fly, at run-time. We won't go into the PHP Reflection API here, but its presence is noteworthy.

  • Improved constructors and destructors - Constructors are functions which are used to initialize objects on instantiation. They are member functions of the class, and automatically run at creation-time to ensure a correctly-built object is present for safe usage. In PHP v4, constructors were fairly basic affairs, and didn't allow clean calls to the relevant superclass constructors; this has been improved. Objects constructed using the new constructor syntax need to include the double parenthesis '()' on the end of the call e.g. $anObject = new Thing(); - the old syntax does not require this. Destructors are new in PHP v5; they do the opposite of constructors, and allow an object to tidy up after itself when it falls out of scope or is destroyed (more on this later).

  • private and protected member variables and functions for objects - private items can only be used by the object itself; protected items can only be used from the object itself and derived objects (subclasses of that class). This follows the C++ semantics for member access (no friends allowed, though), and not the slightly stranger Java semantics.

  • abstract classes (and functions) - Abstract functions are object member functions which are declared but not defined. They provide a contractual interface / format for subclasses to adhere to and over-ride with the appropriate definition for that object. Abstract classes are classes which contain one or more abstract functions. They are intended for subclassing only and cannot be directly instantiated. They are declared as follows:

    abstract class AbstractShouter{
        abstract public function shout();

    They can then be sub-classed using the extends keyword, something like this:

    class AnnoyingGuyAtWork extends AbstractShouter{
        public function shout(){
            echo("GOOD MORNING WANKERS! I WENT TO ...<tune out...>");

  • interfaces - Interfaces share a certain amount of functionality with abstract classes. They are designed to specify a programming interface which an implementing class guarantees to conform to. They contain function declarations (no definitions) and nothing else. In the case of abstract classes, the implementing class must be a derived class (subclass). Interfaces, on the other hand, can be implemented by any class. There are no limits to how many interfaces a given class can implement [9]. Interfaces are declared as follows:

    interface Sleepable{
        public function snooze();

    A class can implement an interface by using the implements (d'oh!) keyword as follows:

    class Couch implements Sleepable{
        public function snooze(){
            echo("zzzz...mmmm...comfy couch....zzzz");

  • The final and constant keywords - final is used to specify that a member function of a given class cannot be over-ridden by a derived class. When applied to an entire class it means it cannot be subclassed. constant is applied to member variables of a given class. It means much what you'd expect - that the variable in question cannot be changed; previously, there was no way to protect a member variable in this manner.

  • Exceptions - Exceptions are quite a large subject and we won't really go into them here (although you may well have seen the term on your Blue Screens of Death or crash windows). In short, they are a combination of a certain type of control-flow mechanism and objects conforming to a certain specification. When an error occurs, the program throws an object (the Exception) containing useful information about the error (often, simply the presence of the object is informative enough by itself). This object percolates down the stack where it can be caught by a dedicated catcher to handle the exceptional condition. If a suitable catcher is not found, the program terminates, often printing the occurence of the Exception to the screen.

    For those familiar with Exceptions, PHP supports the usual try and catch blocks, and the throw keyword. Like C++, it does not support Java's finally clause. Exceptions are such a powerful mechanism that some programmers use them for general control-flow purposes, or message passing, and not for exceptional conditions. For various reasons (usually involving memory or unpredictable flow) this is generally considered Bad Practice® and should probably be avoided.

  • static class functions - This means pretty much what it means in both Java and C++. That is: it is a function which is a member of a given class, but for which there is only one function in memory for all instances of that class - as opposed to all instances of that class having their own local copy. These are often referred to as class members as opposed to instance members.

    What this means, in effect, is that you don't need to have an instance of the class containing the function to be able to call the function. Because of this, they are often used as 'Factory functions'; which are functions that produce fully-constructed objects for use in the calling scope. 'Factories' are generally classes that contain a number of static methods and act as "variable producers" to protect programmers from having to deal with the underlying implementation of a given object. They are often used when the language / interpreter concerned has to make a complex low-level call to the underlying operating system to retrieve some resource. For example:

    $guiWindow = GUIFactory::giveMeAGUIWindowPlease();

  • the __toString() function - When implemented for a given object, this function will be called whenever an echo, print or string-using function is used with this object. This means that when you call echo($myObject); a programmer-defined string (the return value of the __toString() function for the object in question) will be printed. This is similar to overloading the << and associated operators in C++, or implementing the bean-conformant toString() function in Java.

  • Overloaded functions and accessors - Overloading is a way of providing functions of the same name, but with different argument lists, and having the right one called automatically depending on context. To be honest, I haven't had time to figure out the syntax of PHP v5's take on this yet. It looks a lot more clumsy and hackish at first glance than the Java or C++ equivalents, and seems to work via an implied rather than an explicit call. In truth, it's not often needed due to PHP supporting C++-style 'default arguments', but I'll have to reserve judgement until I fully understand it.

  • Altered string indexing syntax - In previous versions of PHP, you could access a character of a string by using the array indexing notation so that, given:

    $aString = "monkey";
    $aString[0] = "d";

    would then contain "donkey". This was confusing and erratic. It was unclear as to whether you were changing the character at the specified offset, or redefining $aString to be a general array with the string "d" at offset 0 (to C programmers, this would be similar to the difference between a char and a char* at the given offset). The new syntax uses curly brackets {} for string subscripting and square brackets [] for arrays.

That ends the whirlwind tour. There are more new developments than have been mentioned here, but these are the most significant.


Philosophizing and Hasty Prose

The first question that springs to mind is: "Does any of this look familiar to any of you?"
Upon encountering the revisions for the first time, my immediate thought was "Hang on; I thought this was PHP". To cut to the chase: It looks almost exactly like Java!

This isn't necessarily a bad thing. Java is an incredibly easy language to write (some claim too easy), and borrowing ideas from other languages is an idea as old as the hills. Bjarne Stroustrup freely admits borrowing most of C++ from C and Simula; Larry Wall (Perl) likewise with sed, awk and shell scripts. The more interesting facets arise when you consider exactly what the point of the whole deal is, though.


i. The Backdrop

I've always been slightly dismissive of using anything more than minimal object-orientation in PHP (and bear in mind that it's C++ and Java which put most of the bread on my table). This has largely been as a result of how PHP works and the way it has been used traditionally.

Usually, PHP has always been deployed as a web-server scripting language. When a request hits the server, the file is opened and parsed through the engine, any necessary extra files are include()ed or require()ed, the localized stack is built, the code executed, the stack collapsed, the content delivered back to the server and thence the client. In this context, heavy use of object-orientation seemed somewhat excessive given that the constructed memory was destroyed at the end of the request chain and would have to be built afresh on each page hit. This means that you have to build a base class, then the derived classes, then use them, then they die: Rinse and repeat. There was no easy mechanism through which to have complex, global, persistent objects hanging around in memory (which would have raised concurrency issues anyway - different requests competing for the same resource).

Using sessions (especially sessions in shared memory or database-driven sessions), or newer technologies like memcached, can alleviate this burden to a fairly large extent [10], but this is still a distance away, functionality-wise, from the way in which Perl and C Modules work. PHP itself is an Apache module, and you script 'to' that module. Perl and C modules act at a lower part of the chain, by being modules themselves and plugging directly into Apache's request cycle as content handlers at any one of the necessary phases. This doesn't necessarily mean that one is better than the other, just that replicating some specific functionality offered by Perl in PHP is difficult, unless you compile-in a custom-built extension yourself which, whilst not rocket science, is not 'trivial' [11].

Things being such, I could only ever see PHP's object-orientation support being useful in the context of encapsulation, aggregation and code organization. Polymorphism of any great complexity seemed to be an unnecessary waste of cycles when compared with the equally-valid procedural equivalent. Of course; this is a criticism which gets levelled at all object-orientation to some degree, but it is not particularly valid. It might vaguely be valid only in contexts where both the objects themselves cannot be preserved and reused, and where blinding speed is imperative (in which case it might be time to break out the assembler anyway). In most other instances, the decisive factor is the decency of the relevant compiler.

The truth of the matter is that situations in which efficiency is of paramount importance are becoming increasingly few. Most desktop computers these days have cycles to burn by the truckload. Varieties of server, games, real-time multimedia manipulation and certain brute-force questions (weather and particle-physics modelling particularly) are some of few domains left where anal attention to speed is the primary criterion. The "speed standard" for the vast majority of other applications is "fast enough". In the instance where you run up against the ceiling of performance, the standard solution is "more hardware" (most weather-modelling isn't done on power-books - yet). This can be evidenced by humble Kuro5hin itself. People point at the MySQL database as being the bottleneck and "not as efficient as x"; strangely, this doesn't seem to bother Slashdot - but look at Slashdot's hardware specs! In short: It's not the database engine.

A server servicing multiple clients with heavy requests is, however, one of the contexts mentioned above, and the upshot of this is that, in certain circumstances, on a webserver, heavy use of PHP's polymorphism can be profligate.

In the interests of honesty; the efficiency and 'relevance' factors were not the only things which were mild irritants about PHP's object orientation. To cap it all off, the syntax was bordering on 'cludgy' as well. I concede this is a highly subjective opinion, but if you're going to borrow syntactic contructs from C and C++; at least make them work as similarly as possible.


ii. The Update

As with any techie whose work involves a given field, I was curious enough to see what the much-vaunted rewrite of PHP would yield. Being busy with other projects when the announcement and early development releases were made, the first concrete information I became aware of was when a friend (primarily a PHP developer) wrote to me a few months ago, quite excited, to outline the new developments, send some sample code and provide links to the relevant URLs. Unhealthily interested myself, I dived into the information (beats working...) and had a total brain freeze:


The part of PHP which I'd always had the least respect for was the part they'd gone to great lengths to extend. Not only that, but they'd rewritten the engine just to support this new expansion. Looking for any non-object-orientation-geared improvements, the only solace to be found was in the aforementioned change to string indexing. In addition to this, they seemed to have stolen most of what syntactically made Java, well, Java; and even the implementation of that seemed to resonate with the syntactic deviations they'd made from C/C++ in the more simplistic object orientation of PHP v4. My reaction was one of mild distaste. Why hack this unnecessary rubbish on to something of which simplicity was always its strongest feature? Merde. [12]

Certain aspects of the implementation began to raise questions. Destructors ? What the hell did they want destructors for? In C++, destructors are mainly used for freeing heap memory which has been manually allocated. If you put the delete or (much less commonly) free calls inside the destructor of a class, you can get it to mop up for itself, the freeing of extra memory is not required - this is pretty much the entire point of destructors. Java uses garbage collection so destructors aren't needed. PHP requires it even less - it is self-mopping in the underlying implementation. PHP.net's own documents write:

"Destructors can log messages for debugging, close database connections and do other clean-up work.".

Well ... I guess ... , but this doesn't seem to offer that much of an advantage over using straight functions. Since v3.0.4 there has a way to specify code to run on request shutdown: register_shutdown_function() behaves in a very similar way to C's atexit() function; registering callbacks to run on termination. In C++ you get some clear tangible benefit from destructors: Build the memory acquisition into the constructor, the memory deallocation into the destructor, and you can pretty much fire-and-forget forever more - it takes care of itself. [13]

In PHP it all seemed so...superfluous: Sure; you can use destructors to close file handles and database connections, but they are no real pain to tidy up manually and, should you forget, unless specifically told otherwise, PHP will close these automatically at the end of the script anyway.

Similar thoughts occurred about some of the other features.

After being mildly glum for all of about eight seconds, the consolation occurred that hey, like C++, at least they didn't force the object-orientation on you; it was there to be used or ignored, as is seen fit. Granted, there were no real improvements from a personal perspective, but they hadn't destroyed any of the things which were good about it, either. I got back to work.

I was slow on the uptake. At lunchtime, the sinister Pinky-and-the-Brain reality finally dawned ...




iii. Dietrologia and Speculation, from the trenches

OK; perhaps accusing them of a covert attempt at global domination is over-cooking it a bit. What seems clear, at least from my perspective, is that the PHP developers are no longer thinking of the webserver as the only 'domain space' for PHP as a product of great utility.

It probably isn't putting it too strongly to state that PHP v5 represents a concerted attempt to break away from the role of 'easy-server-side-scripter', with competing in the role of an all-purpose, easy-to-program, generalized, cross-platform interpreted language being the ultimate aim. They're not just borrowing syntax from Java; Long-term, they're actually going after Java's market niche, and Perl's, and Python's, and dotNET's, and VB's...

When looked at like this, the new enhancements are completely consistent. Elaborate polymorphic programming really doesn't make for a marked improvement, or even a great deal of sense, when used in the create->deliver->kill context of web-page delivery, but it makes an awful lot of sense when viewed from the perspective of a generalized language, supporting large, complex, modular applications that may be running for a considerable length of time. A lot of those features aren't there for convenience; they're there for forward-compatibility; uses which haven't necessarily been dreamed up yet. PHP v5 is not a major-version upgrade so much as a revised statement of intent.

"Looks like a duck; quacks like a duck" abductive reasoning aside, is there any actual evidence that this is what the developers are attempting?

Well, yes and no. The improved object model means that a new level of integration with other technologies is possible, and there are new libraries for COM and dotNET, Java, XML, and Perl. Integration with native code has already been achieved. As previously mentioned, extension libraries can be compiled, fairly easily, directly into PHP itself OR, somewhat in the style of Perl's XS, they can be compiled as external shared library *.so's and either loaded dynamically using the dl() function at run-time, or loaded on process start by configuring the correct options in the ubiquitous 'php.ini' file.

Zeev Suraski, in a high-level overview at Zend.com has written:

" The release of PHP 5.0, powered by the Zend Engine 2.0, will mark a significant step forward in PHP's evolution as one of the key Web platforms in the world today."

It is evident, then, that in the short-to-medium term, the web is still PHP's main battle-ground, although its reach has increased considerably. Its authors now place it firmly in the category of 'platform' rather than 'scripting engine'. This is increasingly a "web world", so it's no surprise that PHP is trying to consolidate and expand on its home turf. What with the creeping sprawl of Java and dotNet in the enterprise market, it was always going to have to do something to catch up / stay ahead / keep pace. But what evidence is there that it may intend to move off the webserver and into the client space?

A surprising number of interesting things are going on in this area.

Probably the most significant development so far was the release of the PHP CLI SAPI module in v4.3.0. This is a binary executable which sits in $installation_prefix/bin (or the relevant installation folder on Windows systems) and behaves in much the same way as the Perl and Python binaries. It supports the running of files which begin with the standard #!/path/to/interpreter syntax, and has a number of command-line switches / flags. 'Neat code' can be executed in a similar manner to the 'perl -e' command, except the 'php -r' command is used instead.

In PHP v5 they've taken the idea a stage further for Windows systems, with a php-win.exe, which is an analog of Java's javaw.exe. This provides the same functionality as the CLI binary, except no console window is needed or popped-up at run-time, and applications / scripts can write directly to and from this executable behind the scenes (this ability isn't needed on Unix systems due to differences in the process control mechanisms).

So the interface for client side applications is already in place. On top of this there have been extensions to the standard API to provide bindings for the Ncurses and Readline libraries. Perhaps the most ambitious binding project undertaken so far is the PHP-GTK project. The bindings for GTK-1 are stable and complete, and work is in progress on writing the bindings between PHP v5 and GTK-2.

So, to the logical question: Have any significant client-side applications been written in PHP?

No; and a quick perusal of the application pages at PHP-GTK and SourceForge suggests it may be a long while yet before we see any. A number of small applications for very specific purposes have been written, and it is perhaps in this field in which client-based PHP will always stay, although perhaps not...


iv. The Shape Of Things To Come ?

The first point to be considered is that, to genuinely extend its grasp, PHP doesn't need to move off the webserver that much. The truth of Sun's high-profile assertion that "The network is the computer", whilst much derided at the time, has become increasingly evident over the years. The current 'hype application du jour' is undoubtedly Gmail: a web-based email application. The browser is becoming increasingly important as network-application-client cast against its more tradional role as remote-document-viewer. Don't argue; The fact you're even reading this is half-proof in itself: Scoop is a content-management application.

Think of the things already possible via a browser: Games, Audio, Video, Animation, Communication, Creative and factual writing, Trade etc. Granted, it's not like you can play GTA: Vice City, or edit real-time high-resolution video yet, but is the day really that far off? It's simply a question of ease-of-use, bandwidth, economics and will. Joel Spolsky deals with this whole issue in last month's excellent article, "How Microsoft Lost the API War".

The second point is that not only is this increasingly a networked world, it's also becoming more and more of an "interpreted world"; by which I mean that many new applications are being developed in non-natively-compiled languages.

Along with PHP, Python has seen an extraordinary amount of growth in the last few years; Perl and Java are being used more than ever, and we've seen the entrance of C#, the new Visual Basic, dot Net, and the whole Common-Language-Infrastructure scenario [14]. This is partly as a direct result of the burgeoning interconnectivity of computing power (it doesn't help that all the variant operating systems and hardware are online, if they can't talk to each other in any useful way) and partly as a result of the ever-onward march of Moore's Law - we're a fair way from the limits of current chip technology yet. Of course, these drivers of change feed back upon each other to an extent.

For pretty much the first time in computing history, applications coded to a virtual machine or interpreter (there is a difference, John Udell) now run faster than they did in native form just a few years ago, and they are only going to accelerate and get more efficient over time. As somebody who actually enjoys C and C++, this both makes me a little sad and brings out a sense of slightly rebellious longing. The idea that two of my favourite languages might, in just a few short years, occupy the same niche that Assembly and Cobol do today is not a particularly comfortable thought. It's never pleasant to contemplate obsolescence, but then: That's evolution. No prisoners.

Stretching the point even further, it's not too far beyond the bounds of realistic speculation to envisage a situation where native, compiled code's only function is to act as a thin gateway to hardware (which, as ever, is the one fixed immovable); upon which the operating system itself would be both a general interpreter and, for the most part, interpreted. Whilst almost inconceivable in the current climate, this would have a dramatic effect on the business, usage and adaptability of all information technology infrastructure as we know it today.

Perhaps it is not intentional, but nevertheless it is this world that PHP is adapting to. Whether it can continue to compete in its current guise is a question only the future can answer. Like HTML, its overwhelming success has come about from its shallow learning curve and ease-of-use. Like HTML, its days are numbered unless it can evolve to be more complex. As the hacker deity in Neil Gaiman's "American Gods" pronounces: "It's all about the dominant fucking paradigm ... nothing else is important". Without really noticing and with all marketing hype cast aside for a moment, at some point in the last few years we really did cross the threshold: The next age is already here.



[1] - There are two points to be considered here.

The first is that determining module usage by analysis of server output (usually the HTTP response headers) is at best an inexact science. Nearly all Apache modules provide some facility for concealing their presence on a server, usually for security-through-obscurity reasons. Concealing PHP is simply a case of setting 'expose_php = Off' in the 'php.ini' file and (somewhat self-evidently) changing 'AddType application/x-httpd-php' to be something other than a '.php' suffix in 'httpd.conf' (a popular option is specifying '.htm' to be processed as PHP and allowing '.html' to be content-handled normally), although most sensible developers are aware that, where servers are concerned, the file suffix doesn't necessarily tell you anything useful. Preventing mod_perl from announcing its presence requires a very lightweight hack to the C source code. There are also countless other methods, including changing Apache's 'ServerTokens' configuration, and running proxy / frontend servers . In short: it's very hard to get demonstrably reliable data by examining server response headers.

For those who are interested, these HTTP responses, although usually invisible to the end-client, can be seen by various means. Telnet-ing to port 80 and issuing a correctly-formatted HEAD request (behave...) will do it, although the Lynx text browser provides a more convenient method, and doing a "View > View Document Information" in Konqueror will also show them, albeit in a reformatted layout. Using Lynx's '-head' and '-mime_header' switches in combination will return the information of a HEAD request, whilst preventing you from entering 'browsing' mode unnecessarily. For example, here are some server response headers from a couple of familiar websites:

> lynx -head -mime_header http://www.kuro5hin.org

HTTP/1.1 200 OK
Date: Wed, 14 Jul 2004 22:20:37 GMT
Server: Apache/1.3.23 (Unix) mod_gzip/ mod_ssl/2.8.6 OpenSSL/0.9.6a
Cache-control: no-cache
Content-Length: 60842
Content-Type: text/html; charset=ISO-8859-1
Expires: Wed, 14 Jul 2004 22:20:37 GMT
Pragma: no-cache
X-Cache: MISS from www.kuro5hin.org
Connection: close

> lynx -head -mime_header http://www.hulver.com/scoop/

HTTP/1.1 200 OK
Date: Wed, 14 Jul 2004 22:22:04 GMT
Server: Apache/1.3.29 (Unix) mod_perl/1.29
Vary: Host
Cache-control: no-cache
Pragma: no-cache
Content-Length: 35423
Content-Type: text/html; charset=ISO-8859-1
Expires: Wed, 14 Jul 2004 22:22:05 GMT
X-Cache: MISS from www.hulver.com
Connection: close

The sharp-eyed will notice that K5's response header makes no mention of mod_perl at all, although K5 is undoubtedly using it (unless the developers have retooled the entirity of Scoop in C, which is a tad unlikely). This exemplifies the inaccuracy mentioned above. The even-sharper-eyed may note that the version of OpenSSL being used is a few Security Advisories behind the times and, in the spirit of open source development, may wish to mention this to the administration...

The second point to be considered becomes self-evident when taking a moment to contemplate the cavernous gulf in reality between development using any programming language, and the soft-focused, pornesque cheerleaders (*pause - look heavenward - stroke chin - or...otherwise...*).

[2] - Some interesting, and slightly odd, information regarding the uniquely quaint and charming British slang phrase "to take the piss" / "taking the piss" can be found here. In all recent contexts, it is loosely equivalent to "making fun of", satirizing, or "having a laugh at a given person's expense". It is not recommended for use in meetings with executives.

[3] - This is very much a digested history. More accurate details are available from the history page of PHP's exemplary manual. It deserves to be mentioned that the manual itself is so damn good that it's pretty much all you need to learn PHP from scratch - and is at least partially responsible for PHP's explosive growth.

[4] - I did try to find a nice piece of suitably-obfuscated, illustrative scoop-code at this point but, (un)fortunately, Scoop is written with surprising clarity (given the nature of the language and the perl hacker's suspect psychology). :-∫

[5] - A nasty little 'feature' of PHP comments is that the single-line versions "comment to the end of the line or the current block of PHP code, whichever comes first " (manual - comments). This means that you cannot use these to comment out a closing PHP tag (?>), or comment out a string containing anything which might match the tag (e.g. XML, regular expressions) and expect it to work correctly. This can be an odd 'feature' to catch, as a line of code which, when uncommented, works perfectly (parses as a string) can often cause the script to break when commented out (parses as a breakout tag) ! The reason for this is because of a fundamental semantic collision between HTML and the newline character. HTML considers the newline character to be semantically meaningless, and in order to facilitate web-designer usage such as -

<p>Hello <? echo($name) ?>. We are <? echo($b0rked) #server error... ?>. Please call back later.</p>

- either the newline had to be made semantically meaningful (which confuses web-monkeys) or the closing PHP tag had to take precedence (which confuses programmers). Web-monkeys are more important than programmers, it seems (yes - it did catch me out once). To get around this, use the C-style multi-line comments instead.

[6] - This is a very terse and slightly inaccurate description of the underlying implementation. Most of the internal definitions are abstracted away using Zend-engine-specific macros and functions. C programmers wanting more details on the 'nuts-and-bolts', and on developing for mod_php itself (adding extensions and extra features etc.) should consult the Zend API section of the manual.

[7] - LongScreedWriter would probably print out this entire article.

[8] - For those interested in the specifc details of PHP v5, php.net has put up a web-page describing the new PHP object-oriented features and syntax which gives a much more thorough (better) flyby than that provided here. Zend have provided a 37-page PDF outlining the new features more fully, although some of this is slightly out of date (for example, they have dropped multiple inheritance in favour of interfaces, and appear to have ditched the delete keyword).

[9] - C++ supports multple inheritance (allowing a class to have more than one direct parent or super-class), so interfaces are not necessary as a core language facility (although programmers can, and do, write their own). PHP and Java, on the other hand, do not allow multiple inheritance (although it was considered for PHPv5) and thus the interface mechanism allows for the flexibility of multiple inheritance without any of its associated 'issues'.

[10] - Incidentally, this is one of the areas for which Zend sells (fairly expensive) proprietary extensions.

[11] - I have no wish to reignite the PHP vs. mod_perl debate; it was stale when mammoth-steak was at the top of the menu and, as Marshall Cline has put it, that kind of argument "generates far more heat than light". They both work superbly and each has advantages over the other. The only thing being discussed is the merit, or lack thereof, of using procedural PHP versus object-oriented PHP on a webserver. Likewise; please note that I'm not saying that "you can't do something in x as well as you can in y". The point is very specific, which is that "you can't do what x does, the exact way x does it , in y", with no superiority / inferiority implied. Whew.

[12] - It transpires that I was in no way alone in this thinking.

[13] - This is a small part of what is often referred to as the 'Resource Acquisition Is Initialization' idiom or technique (pithy name, huh?). It's a key idea in C++, and accounts for a number of issues, including exactly why C++ doesn't have a finally construct in its exception-handling repertoire.

[14] - Whilst many will deride these last examples as both platform and vendor specific, it should not be forgotten that both C# and the Common Language Infrastructure have been standardized (something Sun have not done, and indeed indicated they are not prepared to do, with Java), and that there is a practically fully-functional implementation already available for Linux systems.


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Interpreted / partially-compiled language with longest shelf life:
o ASP 0%
o C# 5%
o Java 16%
o Javascript 6%
o Perl 26%
o PHP 9%
o Python 26%
o Visual Basic 2%
o Other 6%

Votes: 73
Results | Other Polls

Related Links
o Slashdot
o Scoop
o Kuro5hin
o phenomenal growth rate
o most-used Apache module
o mod_perl
o OpenSSL
o gloat about
o fourth position
o unleashed
o cheesily-b egrinned
o Zend
o default arguments
o standard API of functions
o PHP Reflection API
o C++ semantics
o Java semantics
o sessions
o sessions in shared memory
o database-d riven sessions
o memcached
o Perl and C Modules work
o Apache's request cycle
o Slashdot's hardware specs
o borrow syntactic contructs from C and C++
o register_s hutdown_function()
o atexit()
o abductive
o COM and dotNET
o Java
o Perl
o extension libraries
o Perl's XS
o dl()
o high-level overview at Zend.com
o PHP CLI SAPI module
o the Ncurses
o Readline libraries
o PHP-GTK project
o applicatio n pages at PHP-GTK
o much derided
o Gmail
o How Microsoft Lost the API War
o Python
o there is a difference, John Udell
o ServerToke ns
o HEAD request
o Lynx
o Konqueror
o Security Advisories
o gulf in reality
o here
o history page
o manual
o scoop
o manual - comments
o Zend API
o the new PHP object-oriented features and syntax
o 37-page PDF
o proprietar y
o extensions
o Marshall Cline has put it
o I was in no way alone
o Resource Acquisition
o Is Initialization
o why C++ doesn't have a finally construct
o C#
o Common Language Infrastructure
o fully-func tional
o Also by serious articles

Display: Sort:
Zend in the clowns? | 83 comments (72 topical, 11 editorial, 1 hidden)
-1 (1.09 / 22) (#2)
by undermyne on Wed Jul 14, 2004 at 11:32:31 PM EST

didn't use edit queue.

"You're an asshole. You are the greatest troll on this site." Some nullo

PHP v5? Looks like PHP with Java to me. (3.00 / 5) (#12)
by Surial on Thu Jul 15, 2004 at 05:15:00 AM EST

Looking at the new stuff for PHP v5, virtually all the new features listed are direct or almost directly copied over from Java. This is not inherently a bad thing, of course, but one wonders why it was these features that were added.

Does the author of PHP want switching java programmers to feel more at home? Does the author of PHP want to extend the language into the domain of large scale development where Java is definitely used a lot, and claimed to excel (I think so too, but that's a discussion that can take a while)?

Or are the listed features just something all object oriented languages end up growing into?

One thing that strikes me as very odd here is the need for interfaces in PHP. Normally, slow and steady languages like Java use interfaces instead of dynamic mapping ala Python to get around this problem:

with dynamic mapping, you need no interface that asks implementors to have a shoot() method. However, especially in large projects with multiple authors, this tends to lead to shooting yourself in the foot. For small projects, having to define an interface at all just gets in the way.

I always thought PHP was for the 'single author, small project' Rapid WebApp Development kind of situation. Did I miss something or is PHP drifting into some kind of twilight zone where it's neither great for quick development nor for large scale development? Disclaimer: I don't know PHP.

If PHP is trying to do BOTH, I wonder if that works. Two different methods of doing the same thing can lead to difficulties in learning the language and understanding other people's code.
"is a signature" is a signature.

Yes (none / 2) (#17)
by outis on Thu Jul 15, 2004 at 08:08:47 AM EST

PHP is now suitable for use by teams of software engineers, as opposed to the "lone coder" usage that people have typically expected in the past. Assuming that people who learn PHP are able to also learn how to work in a team then we could well see a serious decline in the number of Java users in the next few years.

[ Parent ]
I really doubt that... (none / 0) (#40)
by Surial on Thu Jul 15, 2004 at 04:32:13 PM EST

both because a mixed language has inherent disadvantages, and because of the establishment.

For example: Show me eclipse for PHP. I haven't found it yet. It could of course be written, and perhaps it will at some point. Similarly, show me JFace/SWT for PHP. That might exist, and, again, can be written. But it does have to happen.

Probably even worse is the slow rate at which large software development companies switch languages. That's almost glacial. And would only happen if there's a serious deficiency in the language. I don't see PHP having something unique and uber-useful that java doesn't have - good enough for the larger companies to switch, and with them, a lot of focus on the language.
"is a signature" is a signature.

[ Parent ]

yahoo runs PHP (none / 0) (#42)
by scott reynen on Thu Jul 15, 2004 at 05:04:42 PM EST

the larger companies don't need to switch. yahoo already runs PHP.

[ Parent ]
...as does Hewlett-Packard [n/t] (none / 0) (#66)
by soulman on Fri Jul 16, 2004 at 11:20:19 AM EST

[ Parent ]
Yahoo? Hardly a dev company. (none / 0) (#78)
by Surial on Mon Jul 19, 2004 at 08:19:37 PM EST

Yahoo makes relatively simple stuff in HTML. That's not 'dev'.

Well, if you want to call it that, fine. HTML coupled with PHP should be a good match. Good show, Yahoo.

But that wasn't the type of company I was talking about.
"is a signature" is a signature.

[ Parent ]

Stop the insults... (2.23 / 13) (#15)
by mavetju on Thu Jul 15, 2004 at 07:24:07 AM EST

// string is burped out by ...
function insult($name = "Bob", $phrase = "Screw You"){...
called Idiot. There could then be sub-classes (derived objects) of Idiot called InternetIdiot and Politician. InternetIdiot...
magine Idiot has a member function called saySomethingStupid(), whic...

I like articles better if they don't try to impress 10 year old kids.

It's been, what... (2.62 / 8) (#19)
by Kax on Thu Jul 15, 2004 at 09:03:16 AM EST

two years since that worked on you?

[ Parent ]
Sorry if that annoyed you. (3.00 / 7) (#37)
by serious articles on Thu Jul 15, 2004 at 02:21:41 PM EST

It's a personal thing, but I've always preferred technical books and articles which, when discussing the theory of a particular issue, use highly flippant examples. It lightens the tone. There's little more soul-sapping than people using sales and dry database analogies when they have absolutely no relevance to the point being made. Most people have to deal with enough of that in everyday life as it is.

[ Parent ]
For those watching in black and white (3.00 / 11) (#16)
by brain in a jar on Thu Jul 15, 2004 at 07:42:11 AM EST

The blue ball is the one next to the pink.

The point being that, someone unfamiliar with object orientation is likely to have very little hope of being able to parse this gem of a sentence:

For readers unfamiliar with object-orientation, the basic idea is that sequenced, procedural function calls are replaced by encapsulating most of your code into objects (classes).
Sometimes it is easier to start with an example when explaining something unfamiliar, rather than to start with a string of accurate, but hard to understand jargon.

Life is too important, to be taken entirely seriously.

I understand what you're saying (none / 0) (#61)
by serious articles on Fri Jul 16, 2004 at 02:01:15 AM EST

and it's a good point, but really, aside from the word function and the word classes in brackets, there's no jargon there at all. It parses perfectly well as plain English, regardless of the terms' exaggerated use in programming circles. A non-programmer proof-reading friend didn't have any problems with that particular section.

For people who aren't familiar with OO, an example would arguably be more confusing, as it would be something they hadn't seen before.

[ Parent ]
coroutines (2.80 / 5) (#18)
by sangdrax on Thu Jul 15, 2004 at 08:36:50 AM EST

Why don't they make me able to use coroutines in PHP, so i could do:

do {
  list( $username, $password ) = waitfor_formsubmit();

  $passwordaccepted = (password($username)==$password);
} while( !$passwordaccepted );

such that waitfor_formsubmit() can output a page and wait for the user to press 'submit', and parse the raw result into its return-value.

This instead of needing to live with every page request letting PHP start at the top of a .php script. I /dont want/ to first find out where the heck i was in my code, I want to be able to write the proper control flow in my webapplication.

Note that this cannot be done even in an ugly way without modifying PHP itself, since PHP doesn't support 'goto', and thus doesn't allow me to jump into mid-code after setting all variables.

Concerning OO and their development methods:

They should stop trying to hack and patch up the crappy OO system (granted, PHP5 made it a bit better) and implement stuff which is actually useful for programming web applications.

The OO isn't that useful for PHP imho, since it requires all classes to be reparsed and loaded at every page request, /and/ either all objects being created each page request as well, or them to be serialized/deserialized between sessions, and having to cope with small maximum session sizes or large session load times. Rebuilding an object and class structure every time just isn't my idea of efficiency.

And please, please, don't continuously break downward-compatibility in minor version upgrades. This is /so/ annoying if you are dependant on others (say, several ISPs) on the silent version upgrades of the PHP of your customers.

"coroutines" (none / 3) (#21)
by scott reynen on Thu Jul 15, 2004 at 09:34:45 AM EST

"such that waitfor_formsubmit() can output a page and wait for the user to press 'submit'"

that would require a connection between the user and the server (rather than the browser and the server) that broswers don't allow in HTML, and the developers of PHP can't force them to do it. also, much of what you want would make it pretty easy to crash a server with a poorly-coded (or malicious) script. however, session variables (which you apparently don't like) come as close to that functionality as possible without changing how the browsers work.

[ Parent ]
that's not at all true (3.00 / 4) (#24)
by jacob on Thu Jul 15, 2004 at 10:45:18 AM EST

though it's a common perception. Here's an article about how to implement it with a server alone (server needing to be implemented in a language with special features), and here's an article about how to compile "coroutine-style" CGI scripts into coroutineless equivalents in any language. (And here's a tutorial-style paper about using the specific features provided by the PLT Scheme suite.) I've been using the PLT Scheme web server since it was released about 3 years ago and it's fantastic. Before I became a pointy-headed academy student I developed web sites for a living in purportedly "easy" web languages like ColdFusion, PHP, and others; I'd take the PLT server any day (and I have actually made money rapidly developing somewhat complex interactive systems using it when others said it was too difficult!).

"it's not rocket science" right right insofar as rocket science is boring


[ Parent ]
not true (none / 3) (#27)
by scott reynen on Thu Jul 15, 2004 at 11:18:12 AM EST

if the solution requires a webserver that less than 1% of hosts provide, that's no more something PHP developers could do than if it requires a non-existent browser. i'm no expert on coroutines, i'll admit, but my point that it's not a problem PHP is in a position to solve still stands.

[ Parent ]
Look at the compiler article (none / 3) (#28)
by jacob on Thu Jul 15, 2004 at 11:27:11 AM EST

It addresses this point directly. (And it's fabulous, because I wrote it, so there.)

Also, PHP could do what the PLT server does by implementing for internal use the key feature the PLT server uses (that being first-class continuations; it'd probably be easier to do just for supporting this application than it is in general, but I'm not sure about that).

"it's not rocket science" right right insofar as rocket science is boring


[ Parent ]

404 not found (none / 0) (#41)
by scott reynen on Thu Jul 15, 2004 at 04:55:35 PM EST

the compiler article maybe very well be fabulous, but it's 404 not found.

[ Parent ]
sorry, bum link (none / 0) (#44)
by jacob on Thu Jul 15, 2004 at 05:22:30 PM EST

use tmoertel's link in this thread for the .ps.gz link.

"it's not rocket science" right right insofar as rocket science is boring


[ Parent ]
Regarding the problems with WASH/CGI (none / 0) (#43)
by tmoertel on Thu Jul 15, 2004 at 05:19:22 PM EST

On page 30 of Automatically Restructuring Software for the Web (note: I had to link to the .ps.gz version because the PDF link is broken), it is written:
Thiemann [43] used Hughes's ideas as a starting point and provides a monad-based library for constructing Web dialogs. His monads take care of the "compilation" of Web scripts into a suitable continuation form. Working with Haskell, Thiemann can now use Haskell's type system to check the natural communication invariants between the various portions of a Web program. Haskell, however, is also a problem because Thiemann must accommodate effects (interactions with file systems, data bases, etc) in an unnatural manner. Specifically, for each interaction, his CGI scripts are re-executed from the beginning to the current point of interaction. Even though this avoids the re-execution of effects, it is indicative of the problems with Thiemann's approach.

(Emphasis mine.)

I actually thought that his approach was elegant. Nothing about it prevents the use of more traditional representations of the state of the computation. Rather, his approach gives you a new option: to recompute the current state instead of saving it if the former is advantageous. And, in many cases it is advantageous because you can eliminate the need to store state on the server side of the application by passing a (typically small) recording of the path through the current computation back and forth between client and server.

In large-scale web systems, server-side state is often what limits scalability. Having to maintain state coherence among a large number of web servers means pushing the state back to a central location (which becomes a bottleneck); pinning a session to a single web server for its lifetime (which adds complexity to your load balancing logic, reduces availability in the face of hardware failures, and can still be a bottleneck); or complicating the application logic with code to manage distributed state (which increases both application cost and probability of failure).

With Thiemann's approach, you can ignore these concerns and simply add more boxes to your cluster.

I think it's a very cool approach that deserves more attention.

My blog | LectroTest

[ Disagree? Reply. ]

[ Parent ]
WASH/CGI (none / 1) (#67)
by jacob on Fri Jul 16, 2004 at 11:26:56 AM EST

I like the WASH/CGI approach a lot, but I don't believe you could realistically implement it in a language that wasn't Haskell. It just relies too much on being being pure (to keep path information down) and having various state-encapsulating monads (to easily identify what needs to be saved for the program state to be recreated accurately). So I think someone who wanted to make coroutine-enabled Java would be much better served looking at the fundamental problem (web interaction is call with current continuation) than at the WASH/CGI solution.

I'm not unyieldingly of that position, but explicitly continuation-based approaches seem clearly workable for a wide variety of languages, so it seems to me a more promising road to follow.

"it's not rocket science" right right insofar as rocket science is boring


[ Parent ]

Care to elaborate? (none / 2) (#29)
by tmoertel on Thu Jul 15, 2004 at 11:30:13 AM EST

that would require a connection between the user and the server (rather than the browser and the server) that broswers don't allow in HTML [sic]
Why can't the web/app server provide an abstraction to hide the request-and-response nature of HTTP, making the flow of control seem linear to the server-side programmer? (You might want to take a look at Web Authoring System Haskell (WASH) or the use of continuations for web programming before answering.)

My blog | LectroTest

[ Disagree? Reply. ]

[ Parent ]
request/respone abstraction (none / 0) (#73)
by sangdrax on Sun Jul 18, 2004 at 09:43:21 AM EST

That is exactly what i meant. HTTP shouldn't change as it is the core of the WWW.

the 'wait_for_submit()' is essentially a routine which outputs a html page, saves the state like a session and aborts. The next time the page is called (with the same session id, or some other construct), it just starts the script right after the abort and has the GET/POST variables available.

That this could result in unsafe webpages does not have to be true. Ofcourse, it is possible for any system to be made insecure by lousy programming. And, register_globals should be disabled, even more so as for normal PHP apps. The information returned by the user submit ($GET, $POST, whatever) can be entirely contained in the return value of the function which is called to do the abort-and-resume.

Note that a 'global' $GET and $POST has far less value in such an environment. It is only useful to get the parameters for the first call to the page, when there is no state to resume.

The saving of state is ofcourse a matter of concern. Proper programming shouldn't result in a large amount of useless global variables and the like. The saving of state has to be weighed against the constant rebuilding of state by reparsing the included php scripts and requerying required information from the database or files, as well as still parsing the data that is registered in a session. If this balance doesn't work out in your situation, don't use the construct (too often). I admit it is hard to tell in advance how often this balance doesn't work out in favour of this construct, since it could also require a different PHP programming style, but that does not mean it can be very useful in many situations and can greatly enhance PHP's programming power.

Even only very weak versions of this concept (f.i. only save the call stack and the registered variables in the session, overwrite $GET and $POST, forcing the programmer to parse them immediately) could already prove to be a powerful tool.

It could even allow far safer programming than is allowed now: at the moment i have to check at the top of every PHP script if the user is allowed to access it, and is in the right state to access it (step x of a form should only be accessed after step x-1, for instance). With constructions as I mentioned earlier, this state is essentially guaranteed, and I don't have to worry from where the user came. I can essentially then program like I can program normal apps and not be crippled by the current request/response mechanics.

[ Parent ]

ASP.NET (none / 1) (#76)
by IntlHarvester on Mon Jul 19, 2004 at 02:35:04 PM EST

For good or bad, ASP.NET essentially abstracts out much of the HTTP request/response cycle. It does this by cramming the page state into a big ASCII hidden form field blob so that the server isn't holding the state for every user.

(Rather than a "waitfor_formsubmit()" function, you code against a submit event.)

The problem with this approach is that the coder SHOULD be conscious of the HTTP cycle and should not be encouraged to POST to the server when the operation could be performed on the client.

[ Parent ]

Well done (2.66 / 6) (#20)
by jmzero on Thu Jul 15, 2004 at 09:24:42 AM EST

As someone who hasn't played with PHP much, I'm not too interested in whether OO-ism is defiling PHP.  I did find this article to be a great summary of PHP, what it's good for, and where it's going.  Thanks.
"Let's not stir that bag of worms." - my lovely wife
Ye Suffering Gods... (1.00 / 19) (#22)
by gordonjcp on Thu Jul 15, 2004 at 10:00:48 AM EST

... this is on the front page? It's a rambling, stolen-looking crock of shit. And from a nullo, too

Give a man a fish, and he'll eat for a day. Teach a man to fish, and he'll bore you rigid with fishing stories for the rest of your life.

Really? (2.75 / 4) (#23)
by marksetzer on Thu Jul 15, 2004 at 10:09:46 AM EST

I take issue with this statement:
Similar modularization can be achieved on Unix systems, but most people statically compile the requested libraries directly into PHP (and some then statically compile PHP directly into Apache).

Really, is this what most people do? I mean, Imust have compiled PHP dozens of times over the years and practically every time (per the installation instructions) I've specified an APXS location to compile the thing as an Apache DSO. I know there's no "right" and "wrong" way to do it, but isn't that the whole point of DSO and loadable modules? Even most linux distributions that give you a precompiled binary still have some installer script to configure Apache and run APXS. Isn't this how most people are doing it? Is there some disadvantage to doing it that way that I'm missing?

If a smoking ban will actually cause Houston to fold up and disappear, then I'm all for it. -rusty

Apache DSO (none / 1) (#33)
by rusty on Thu Jul 15, 2004 at 01:26:32 PM EST

Generally if all you want is one module, DSO works fine. But, though it has been improving, there are still some module combinations that don't play well together unless they're all statically compiled. It doesn't seem to be predictable which ones will fail and why.

Also, on any kind of a production machine you usually know for certain what your apache requirements are going to be. There isn't really any advantage to not compiling what you need in statically (since you already know you're not going to wake up tomorrow and say "oh, hey, I suddenly need mod_php!"). So even a slight risk of problems with dynamic modules pretty much overrides the complete lack of benefit from them.

I would have agreed with the authors statement (that "most people" do it statically) but I have no idea in terms of actual numbers.

Not the real rusty
[ Parent ]

Yes. (none / 0) (#36)
by serious articles on Thu Jul 15, 2004 at 02:12:53 PM EST

I was vague there, because I didn't want to get caught up in a deviation over the whole compilation->linking issue. It can become quite a "hot" topic.

The section you've quoted was discussing that those "modules" which ship with PHP end up being built into PHP itself. It doesn't matter whether you're using a lib*.so (which, as you say, is common) or a lib*.a - they are internal to the PHP libary.

Run your libphp.so through nm and ldd sometime. You'll see that, threading libraries, the standard C library and some integral system libraries aside, the only libraries which are dynamically linked are those ones for which you've specified:
and not the ones for which you've done:
during the ./configure phase.

In contrast, on Windows systems, those extra modules come as external DLLs, which you have to include-or-not in 'php.ini'. Contrast the contents of the 'ext' directory in the unix distributions and the 'extensions' directory in the Windows distributions to see what I mean. The unix modules come as source, the windows ones don't. You may not be aware of it, but it is perfectly possibly to compile those internal modules as separate *.sos, in a similar vein to doing an --enable-shared=rewrite on Apache.

[ Parent ]
I hate the way PHP tends not to be retrocompatible (2.83 / 6) (#25)
by l3nz on Thu Jul 15, 2004 at 10:49:07 AM EST

One of the reasons I use PHP but I don't trust it is that it tends to break compatibility at random. If you look at the docs, you'll find that sometimes a function changes its behaviour or expected inputs between a revision and the other. Java stuff - just to name one - may be ""deprecated"", but keeps on working without breaking your existing codebase. -1 for PHP.

Do you remember when they changed the default behaviour to not importing variables directly? how many providers adopt it now, after more than a year? it would have broken all existing stuff. This is not a way to lead the developement of a programming language.

I frankly don't need all this new stuff that comes with PHP5 - when I need it, I use Java that's by far more reliable. I hope my hosting provider never upgrades to v5 - I would prefer avoiding the nuisance of retesting everything for getting no useful advantage over what I have today.

By the way, the language had vast areas of improvement - the way it handles arrays with the foreach is awkward at best. PHP remains a weak language in my opinion - OK to format HTML and do a couple of queries, but nothing I'd write an enterprise grade application into.

Popk ToDo lists - yet another web-based ToDo list manager. 100% AJAX free :-)

Ah, the good old days... (none / 1) (#58)
by ubernostrum on Thu Jul 15, 2004 at 11:52:56 PM EST

Do you remember when they changed the default behaviour to not importing variables directly? how many providers adopt it now, after more than a year? it would have broken all existing stuff. This is not a way to lead the developement of a programming language.

If you're talking about the change in the default setting of register_globals, then I'm afraid you're a bit off. People who knew what they were doing before didn't have problems (because they were already using "safe" methods like the superglobal arrays) and people who didn't know what they were doing had to learn.

You cooin' with my bird?
[ Parent ]
You sure they learnt? (none / 1) (#60)
by l3nz on Fri Jul 16, 2004 at 01:27:22 AM EST

I have been using quite a number of different hosting providers offering PHP for a number of projects, and I fear that NOT A SINGLE ONE of them has register_globals enabled for fear of breaking existing stuff. So it wasnt't a success story, was it?

Popk ToDo lists - yet another web-based ToDo list manager. 100% AJAX free :-)
[ Parent ]

That's a great success... (none / 1) (#62)
by Wiggy on Fri Jul 16, 2004 at 04:18:14 AM EST

... for the script kiddies who are going to trash your code.

You miss the point made by the orginal replier - most coders didn't need to change. We aleady knew what we were doing. You didn't, and neither did most of the people writing code on your hosting provider's boxes. As a result, you have a choice - learn what you're supposed to do, or get 0wned. Your call. The only error the PHP team made in this was not making the switch a long time before.

[ Parent ]

Sure (none / 0) (#72)
by l3nz on Sun Jul 18, 2004 at 07:02:53 AM EST

The point is that they can break YOUR code too, because you're using a managed hosting service. So what?

And I would not call myself a coder if all I was to do was PHP.

Popk ToDo lists - yet another web-based ToDo list manager. 100% AJAX free :-)
[ Parent ]

I'd suggest you take a look at PHP5 - really. n/t (none / 0) (#75)
by Wiggy on Mon Jul 19, 2004 at 09:10:47 AM EST

[ Parent ]
Very interesting (3.00 / 6) (#26)
by jacob on Thu Jul 15, 2004 at 10:54:29 AM EST

Thanks for this article. I'm always glad to see interesting tech articles here. Sorry I didn't see it in time to vote for it; consider this an ex-post-facto +1FP from me.

About your analysis, though: I don't think it's really legitimate to attack PHP for being inefficient the way it handles objects (parsing and building lots of ancillary stuff at every invocation) for a few reasons: first, PHP 5.0 was released in conjunction with a compiler that presumably eliminates most or all of the performance penalty (yeah, it's expensive, but that's a separate debate point), and second, as you said, there's no point in taking away features developers find useful because of a performance penalty that doesn't make performance unacceptable. If you couldn't avoid using those features, then I could see the argument that uncompiled PHP wasn't suitable for large sites, but you can, so that's not really an appropriate argument either.

"it's not rocket science" right right insofar as rocket science is boring


Very true. (none / 1) (#38)
by serious articles on Thu Jul 15, 2004 at 02:39:46 PM EST

This article, really, is not so much about the new features or the direction of PHP, even though they are very much relevant, but more about having one of those realisations (probably long after everyone else) that technology genuinely had evolved during the last few years. New things were becoming possible etc.

There's a tendency (on my part at least) to adopt a slightly cynical, head-down, beavering-away attitude where half the announcements sound like hype and vaporware, and the rest sound irrelevant to your particular travails. In the wake of the dot com crash, it was hard to avoid a feeling of stationary "treadmillism". Like glaciers, I imagine: You don't look at them for a few months and suddenly they're half a mile further down the valley.

My opinions on the new features of PHP were just that: opinions, and in part they were formed by head-scratching bemusement at not seeing their relevance at first. The new OO is interesting in that it actually maps to a different (procedural!) model under the hood than how it appears on the surface. Undoubtedly, developers really want these features: They are mainstays of the newer-school approach, and very useful, not least from a conceptualisation point-of-view, and it is to this demand to which PHP development is responding.

[ Parent ]
php-gtk ... (2.75 / 4) (#30)
by joeldg on Thu Jul 15, 2004 at 11:43:50 AM EST

the reason for php-gtk not getting a lot of programs is that a lot of people don't even know it is there or how to use it. There is a lot of very cool things you can do with it that are pretty cool.

I wrote a tutorial on writing skinnable desktop apps with image masks (transparent parts) here: http://lucifer.intercosmos.net/tut/

And another on working with animated graphics and sprites here: http://lucifer.intercosmos.net/phpgtk/

I have extended the sprites demo (though not live just yet) to have the mapping functions, tile properties and redrawing the map field based on view, as well as having a system for adding in sprites on the fly and and loading maps from servers and handling overlays (plants) etc.

Anyway, just know there are people working on making php-gtk apps common on the desktop.


--------- joeldg
Good features (none / 2) (#31)
by Spendocrat on Thu Jul 15, 2004 at 12:27:13 PM EST

As someone who spent half a year implementing a major web application in PHP, these are all features it would have been nice to have.

I don't see namespaces there though, sadly - they'd be nice to have.

PHP - how did it come so far? (2.00 / 14) (#32)
by K5 Troll Authority on Thu Jul 15, 2004 at 01:13:15 PM EST

PHP is a convenient language for rapidly prototyping simple dynamic websites. Websites thus built can in many cases be deployed indefinitely, without spending time and money on refactoring code in a different language. PHP's simplicity makes it a good language for inexperienced programmers, such as those moving from a pure page-design role to a site development one.

For more experienced developers, though, the language's simplicity rapidly turns into complexity, slowing down the development process. These developers are the ones who have the skills needed to build large and/or complex websites; using PHP for such sites therefore tends to be a net loss. This tendency is reinforced by PHP's lack of the linguistic features needed to promote working on large software projects. If your project is at all large or complex, it may be better to look elsewhere when choosing an implementation language.

In cases where PHP has been determined to be inappropriate, what language should be used? There is considerable choice here; few languages are as bad as PHP for doing serious development work. PHP should be recognized for what it is and any serious website or news group must stop hailing it as anything other that an overgrown hack. The fact that so many people actually like PHP is only an indicator of the poor intellectual level of these people and how little they actually know.

K5: we get laid more than Slashdot goons — TheGreenLantern

You know... (none / 1) (#57)
by ubernostrum on Thu Jul 15, 2004 at 11:44:57 PM EST

You could at least write your own material.

You cooin' with my bird?
[ Parent ]
it came so far because it is simple (none / 1) (#74)
by muyuubyou on Sun Jul 18, 2004 at 03:05:00 PM EST

PHP has (until 4 at least) a niche. It's great for quick development of web sites that often change so quickly a whole design is not possible, thus the lack of artifacts keeps you from shooting yourself in the foot by closing and packaging your design too clickly. Other that this AND availability, PHP is only the way to go if you're not proficient in Perl, Ruby, Python (assuming tasks you'd do with a scripting language). JSP is also a good alternative but the reference implementation (Tomcat) is way too slow compared to propietary ones, and servers supporting it are fewer and more expensive. So it's not a real alternative for the mass.

PHP used to be essentially different to Perl, Ruby or Python. PHP object orientation was minimal and used only for 3rd-party packages (which is the way it should be in web apps) and it's syntax is also very simple. The other three have just too much in common and thus compete in a different level. None of them was made to be embedded in html code. This is very dirty from a classical programming point of view, but has its uses.

In my opinion, Perl is essentially better than PHP at anything except simplicity. Perl is also too easy to obfuscate. Perl is very popular in OS installations, but it's second to PHP as an Apache module. Perl is often faster and has a high quality repository (CPAN) that beats PHP's PEAR any day of the week. Perl will hardly beat PHP in popularity for web programming since it's too difficult for the average PHP coder - it has way too many established idioms and you are supposed to know way too many modules.

Ruby and Python are no real alternatives where PHP is king, because they're usually not available except running as CGI, then the performance penalty is pretty disencouraging. I prefer Ruby to Python and I'd love it if mod_ruby was more popular.

[ Parent ]

Whiespace and comments (none / 1) (#34)
by samjam on Thu Jul 15, 2004 at 01:29:31 PM EST

Put your whitespace in the php

Hello <? echo($name) ?>. We are <? echo($b0rked) #server error... ?>. Please call back later.

It also lets you interleave nesting between html and php

Whiespace and comments (none / 2) (#35)
by samjam on Thu Jul 15, 2004 at 01:30:05 PM EST

Put your whitespace in the php

<p>Hello <?
?>. We are <?
#server error...
?>. Please call back later.</p>

It also lets you interleave nesting between html and php

i'm not excited about php5 (none / 2) (#39)
by reklaw on Thu Jul 15, 2004 at 03:57:00 PM EST

...but that's probably just because I hate the huge mess of useless language features that is Java. The only reason I'd ever want to move to PHP 5 is some of the features it adds (I could have done with scandir recently, for example).

Also, PHP-GTK sucks. If someone writes wxPHP, though, I might use that.

Trickiness. (none / 1) (#45)
by serious articles on Thu Jul 15, 2004 at 05:35:24 PM EST

I think most people's rection to PHP5 has fallen into one of two distinct groups: The "But ... why??" camp, and the "OO ... cool!" faction. I tend to agree with you. I'm not convinced that, for what I use for, the new features add much, if anything. It's about providing options: conceptual as well as concrete; being many different things to many different people etc.

I quite like Java's elephantine sprawl; it enables you to get things done very quickly, as the API covers practically everything you might ever want to do. Although; sometimes you can't help feeling that, given the time taken to actually find what you're after, it would sometimes have actually been quicker to just have sat there and written the damn thing straight away. I can fully see the argument of people who say that it's like distributing Perl with every single CPAN module bundled-in.

Also, PHP-GTK sucks. If someone writes wxPHP, though, I might use that.

That's a tricky one. The wxWidgets stuff is a C++ wrapper to system-specific libraries, one of which is GTK anyway on unix systems. Writing hassle-free PHP extensions in C++ is still something of a black art, although information is starting to emerge, mainly through trial and error. From personal experience, it's far easier to do it in C. I'll hold my hand up to being pretty damn ignorant when it comes to Python, but it seems that their native extension mechanism works in a completely different way, so maybe this is why they seem to have had little trouble getting it to work.

[ Parent ]
prety horible post ..... (1.85 / 7) (#46)
by weks on Thu Jul 15, 2004 at 05:47:17 PM EST

pathetic hackjob of perl...
painfuly horible perl-clone...
perl hack for pansies.....
pointlesss heap of ppluplpglpulphhhggguuuhhghh...!!


[ \@o@/ | weks! ]

People Hate Perl [n/t] (none / 0) (#64)
by hovik on Fri Jul 16, 2004 at 08:52:29 AM EST

[ Parent ]
Perl Has Problems [nt] (none / 1) (#79)
by SoupIsGoodFood on Mon Jul 19, 2004 at 11:27:25 PM EST

[ Parent ]
Well, this is just adding OO to a dynamic language (none / 2) (#47)
by p4r on Thu Jul 15, 2004 at 07:50:44 PM EST

I am not a PHP user. But I play one on K5. The old OO model in PHP was pretty broken. So Zend made a new one, that looks like a mix between lua's, Python's and Java's. This looks pretty reasonable to me. Since one important feature of PHP is being C-like, it makes sense that its OO syntax resembled that of C++/Java. PHP started as a web scripting language. Perl as a Unix administrative tool. Both have evolved way beyond their original uses. I know quite a few people using PHP for general scripting purpose because they like the syntax. It's not the cleanest, most orthogonal in the world, but it feels right and is productive for a lot of programmers. And I'm sorry to break it to you, but C/C++ will probably lose their mainstream relevance in the coming years. It is quite strange that languages with manual memory management are still mainstream in 2004 when good GC has been available for decades now. Ok, so what python/perl/php do is merely refcounting, but these techniques exists & are commercialy used.

Clean? (none / 0) (#51)
by Mason on Thu Jul 15, 2004 at 10:07:32 PM EST

Java was hacked together for TV set-top boxes.

C++ is object-oriented lipstick on a procedural pig.

And so forth...

SmallTalk, C#, and a few others are the only languages I'd consider "clean" in their conception and implementation.

[ Parent ]

I don't understand (none / 0) (#53)
by p4r on Thu Jul 15, 2004 at 10:37:32 PM EST

I never said any of the languages I mentioned were clean. Well, I think Python is. kind of. Scheme can be clean. Oz, IMHO, is. To me, PHP is Just Another Dynamically Checked Language Running On A Virtual Machine (JADCLROAVM), and I know people who like it a lot, so it must have some redeeming qualities.

[ Parent ]
Too much Java, not enough Python. (none / 1) (#56)
by ubernostrum on Thu Jul 15, 2004 at 11:42:02 PM EST

I sense the oncoming rush of public static void abstract bloody fucking stupid syntax not going to stop yet still got another keyword in there function foo().

You cooin' with my bird?
[ Parent ]
couple thoughts (none / 1) (#71)
by Zaak on Fri Jul 16, 2004 at 09:41:20 PM EST

And I'm sorry to break it to you, but C/C++ will probably lose their mainstream relevance in the coming years. It is quite strange that languages with manual memory management are still mainstream in 2004 when good GC has been available for decades now. Ok, so what python/perl/php do is merely refcounting, but these techniques exists & are commercialy used.

Until someone writes a widely accepted operating system in a language with garbage collection, C and C++ will retain their mainstream relevance. Do you see any operating systems being written in (for example) Lisp, or C#?

Also, just to be pedantic, Python's garbage collection has been refcounting + cycle detection since 2.0 (late 2000).


[ Parent ]

Where PHP needs to go. And why it won't go there. (3.00 / 4) (#48)
by static on Thu Jul 15, 2004 at 09:22:57 PM EST

Having spent 3 years doing intensive intranet programming in PHP v4, I can appreciate what v5 brings to the table. I hit the limitations of the objects in v4 quite a few times; static class variables was the most recent one. [I should note that v4 had static class methods, but not static class variables.]

But there are other limitations in the language that are much harder to move away from and I doubt they'd even try.

First is the semi-colon. The only benefit it has it to make the language parsing easier. Unfortunately, this means the programmer is inconvenienced and I know I've lost countless hours (over time) - perhaps weeks - re-running a page only to see it fail because I've forgotten a trailing semi-colon. Icon is a reasonably similar langauge that has long done without, although you can use it if you like, and the freedom from requiring such a simple thing is liberating.

Second is a small number of syntactic warts, first and foremost is array(). Modern list constant notation usually uses [ ] and that would be a huge improvement in PHP's readability and maintainability.

Third is the horrible isset() concept and construct. I briefly suffered through Visual BASIC's need to distinguish between a variable not existing, being Empty or containing Nothing or Null. PHP's insistence on distinguishing between an unset variable and one containing NULL is not as painful but still unnecessary. And the awkward pseudo-function isset() does not help. At the very least a simple prefix operator (like Icon's /) is needed.

PHP is a language slowly growing up. Version 5 is a good step forward, but I think there is still further to go.


What about... (none / 2) (#50)
by Mason on Thu Jul 15, 2004 at 10:01:24 PM EST

The all-ighty ollar:  $.  Don't tell me there's no way to tell what's an identifier without those.

Semicolon isn't too bad on QWERTY keyboards.  Plus it lets you split lines without appending a character.  I'll concede that a clever parser should be able to figure it out without either mechanism, but you'd need a pretty solid proof that there are no valid adjacent C++/PHP lines of code that would be ambiguous without the semi.  Tricky.

But overall, PHP is more than a few syntactic tweaks away from being a perfect platform.

[ Parent ]

The dollar and the semi-colon. (none / 1) (#52)
by static on Thu Jul 15, 2004 at 10:26:42 PM EST

Yeah, I'd like to lose the dollar sign, too. However, I know enough about language design that that would have quite a major effect on the parsing engine. It also alters the way the namespaces work, possibly in an incompatible way.

Losing the semi-colon should be easier. The way it works in Icon is if there is an incomplete expression at the end of a line (this is key to how it works), then keep going with the next line, otherwise assume an implicit semi-colon. This also means you can still use a semi-colon if you want two statements on the same line. I've found this happens very rarely, even in PHP.


[ Parent ]

A toy example (3.00 / 4) (#63)
by gazbo on Fri Jul 16, 2004 at 04:56:54 AM EST

Of the problems in removing the semicolon.  Note I'm ambivalent to it; JavaScript has optional semicolons and works just fine.

$array = array('foo','bar','start','data','moredata');
$i = 0;
while ($array[$i++] != 'start');
echo $array[$i];

Note the semicolon after the while statement.  When run, this program will scan the array, and print the first element after the 'start' token.  What would it look like without the semicolon syntax?  Presumably you'd have to write something like this:

while ($array[$i++] != 'start'){}

Now that's no hardship, and this example is pretty contrived anyway, but you see that these semantics need much consideration, and can affect existing code.

As for the $ signs, they allow some clever stuff.  Automatic expansion inside double quotes is the obvious example, but (if I could just wake up) there are more complex things too.  Thing is, after a while the dollars become second nature; I really don't notice or care whether I'm using a language that uses the dollar prefix.

Topless, revealing, nude pics and vids of Zora Suleman! Upskirt and down blouse! Cleavage!
Hardcore ZORA SULEMAN pics!

[ Parent ]

How would variable variables work (none / 0) (#80)
by outis on Tue Jul 20, 2004 at 06:06:55 AM EST

if you removed the $ from the front of variable names?

[ Parent ]
You'd use $ only in front of variable variables... (none / 0) (#81)
by QuickFox on Fri Jul 23, 2004 at 12:54:41 AM EST

...and in double-quoted strings.

You wouldn't have to use it all the time, only when it's useful, only when it conveys some meaning.

Give a man a fish and he eats for one day. Teach him how to fish, and though he'll eat for a lifetime, he'll call you a miser for not giving him your fi
[ Parent ]

That occurred to me (none / 0) (#82)
by gazbo on Fri Jul 23, 2004 at 05:21:58 AM EST

But there is a lot to be said for consistency.  If you force the use of $ in front of variables then the downside is 1 extra character each time, but the upside is that variable declaration and access is always consistent.

As a lame example, I keep getting caught out when writing bash scripts - I'll write something like:


When of course one shouldn't use a $ during a declaration.  By not only allowing, but forcing a $ to be used, this kind of silly mistake would be impossible.

Topless, revealing, nude pics and vids of Zora Suleman! Upskirt and down blouse! Cleavage!
Hardcore ZORA SULEMAN pics!

[ Parent ]

my annoyance (none / 3) (#65)
by duffbeer703 on Fri Jul 16, 2004 at 09:08:08 AM EST

i cannot stand using punctuation marks when i write it's not like those pesky periods commas and question marks have any real purpose in my opinion punctuation is a creation devised by english teachers to mark students down it doesn t really serve any other purpose

if you really hate semicolons and stuff i suggest you try python you will need to count spaces and stuff but that semicolon will go away

[ Parent ]

To whom are these features new? (none / 2) (#49)
by Mason on Thu Jul 15, 2004 at 09:52:15 PM EST

I'm glad to see that PHP is implementing the base features expected of any non-kiddie OO language, but PHP is still a few generations back from the serious web application environments. I can't speak for J2EE, but ASP.NET has a pretty solid implementation of server controls that makes complex web UIs a ton simpler to code and deal with. PHP, like old-school ASP, is still stuck in the GET/POST model, and the weight of that falls solidly on the developer. Server controls let you do web UIs the same way you'd do desktop UIs, where it is entirely event-driven, and the controls can be accessed as rich objects instead of raw HTML strings. If PHP is moving in this direction, kudos. But right now it is straddling the divide between lightweight post-Geocities web-newb playground and serious web application platform, and lacks the conviction to progress further toward either side. I don't get paid by the hour though, so I'll stick to more robust environments.

How many generations of serious web apps? (none / 0) (#54)
by p4r on Thu Jul 15, 2004 at 11:23:25 PM EST

The Web has been here for 10 years or so.
  • 1st: static pages back in '94
  • 2nd: original CGIs in perl and C ('95?)
  • 3rd: mod_perl, tcl in AOLServer and the like (95-96 or so)
  • 4th: PHP, classic ASP, 100s of python frameworks, ColdFusion (97 onward)
  • 5th: Huh.. ASP.Net, J2EE
  • 6th: hrm.
So that's 1 generation, unless you can put something between ASP.Net and moderm LAMP.

[ Parent ]
PHP is still crap (none / 1) (#55)
by czth on Thu Jul 15, 2004 at 11:41:07 PM EST

Some problems may have been ameliorated in version 5, but the language is still fundamentally anti-programmer, good only for the first five minutes of a newbie's intro to programming, and then doing uncountable damage that, at that tender age, causes scarring that takes far longer to repair.

Oh, you want documentation? I've quite a collection - enjoy.

I've just started playing with HTML::Mason, and it's a joy to use... nothing at all like PHP: modules, components, flexibility, power.

But I guess languages like PHP and VB provide good work for those of us that are called to come in and fix the resulting messes, so they're not all bad.


+1 FP just for this (none / 2) (#59)
by m a r c on Fri Jul 16, 2004 at 12:35:19 AM EST

The syntax of PHP looks like the offspring of a drunken alley-fondle between C and Perl.
I got a dog and named him "Stay". Now, I go "Come here, Stay!". After a while, the dog went insane and wouldn't move at all.
PHP5 on Windows (2.25 / 4) (#68)
by trueroms on Fri Jul 16, 2004 at 12:12:15 PM EST

For those of you who'd like to test PHP 5.0.0 by themselves on Windows, we've packed a new release of WAMP5. It comes with apache, mysql and a service manager.
Have fun ;-)

ahh... php (1.00 / 4) (#69)
by Willie Dynamite on Fri Jul 16, 2004 at 02:45:15 PM EST

a language so crap it makes perl seem like a good thing.

I'm not sure... (none / 0) (#70)
by werner on Fri Jul 16, 2004 at 06:18:25 PM EST

I would say, "a language so easy, it makes anything written by a programmer a good thing."

[ Parent ]
wait... so... (none / 1) (#77)
by sallgeud on Mon Jul 19, 2004 at 05:52:14 PM EST

PHP girls like to fuck mod_perl boys?  Does mod_perl2 mean I qualify for a tag-teaming?

Unicode? (none / 0) (#83)
by UnConeD on Mon Jul 26, 2004 at 09:14:32 PM EST

I can't believe you did an article that long about PHP5 without even mentioning PHP5's total lack of Unicode-support once.

PHP's lack of Unicode support is hell for those who want to develop large, multilingual apps that run on most PHP installs. You see, PHP's biggest advantage is that you can get a webhost with PHP installed for almost no money. The downside is that most of those hosts run the bare-bones, default PHP install, some even a locked down one, and don't allow any changes.

So, in spite of the non-default extensions that are available for Unicode and general multibyte string processing, PHP does not 'do' Unicode if you want to your PHP application to run on the majority of installs out there.

All the major web languages have proper Unicode support, except PHP. PHP5 could've made a difference, but it didn't.

Zend in the clowns? | 83 comments (72 topical, 11 editorial, 1 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!