Now according to Robin Luckey’s report, PHP has seen 20% growth in terms of LoC; code written in Ruby simply dwarfs in comparison. Though I have a strange feeling about this.

I believe that this year, and the one to follow will put Ruby (and especially Rails) where PHP was back in 2002-03; in a sense Ruby will enjoy the growth in popularity and adoption the same way PHP did. But putting aside technological merits, I think that there’s a categorical difference between most code written in PHP and that in Ruby… in a Apple vs. Microsoft kind of way.

For starters, Ruby (and especially Rails) tend to spoil developers. The minimalistic approach of both the language and the framework affects the developers’ mindset, and makes them, even forces them to write more concise code. PHP has a history of ugly code, amateur software and “failed” frameworks. So the code produced by most PHP’ers would have a much larger LoC value than similar code produced by Ruby’ists.

In addition to that, most projects written in Rails are service-oriented: not open source, no public code repository, and no way Ohloh can analyze them. Most of the Ruby code that Ohloh can analyze comes from RubyForge, which accounts for most projects written in Ruby, and none of those, relatively speaking, have a large code base.

I neglect the effect of 37signals’ product design and marketing approach, though I know it’s in the back of every Rails developer’s mind. Most sites built with Rails are usually simplistic, and don’t require much code in the first place. And even if Ohloh had access to these sites’ code, they wouldn’t see much growth anyway, because once a service-oriented site is complete, feature-additions will only account for a thin slice of its growth.

Remember, the numbers on Robin’s report are those of growth not of total LoC. That is, PHP has grown by 20% even with Rails’ influence over web developers. I can only find two reasons for that:

• PHP code is inherently more verbose, thus generates more lines of code.
• Developers prefer switching frameworks than switching languages.

Three or four years ago I used to get excited about PHP releases, I remember how big was the jump from 4.0.6 (read buggy) to 4.1 (read cool). We all know it was the 4.x tree that caused everybody to hail. We compared it to 3.x, we liked it a lot. Not because 4 became object-oriented, not because 4 introduced tons of features, but because 4 made it much easier to do what we do best: make stuff.

I would argue that PHP’s next major tree was the 4.3, but then things stated getting out of hand. Everybody started getting touchy feely about the “enterprise”, we wanted to prove that PHP can make, that Java’s no better. Remember the PHP vs. Java, PHP vs. ASP.NET, PHP vs. Fluffy Puppies debates? Benchmarks? Micro-scrutinizing? strstr vs. str_str? I do, and I couldn’t bare it. I couldn’t care less whether PHP was enterprisey or not, I just wanted to make stuff, I wanted a sharp tool, a single tool, not a swiss-army knife, and I’m sure many PHP developers would agree.

PHP5 couldn’t make up for it. Admit it. Deal with it.

PHP5 introduced all sorts of bells and whistles, a whole new OO model, SimpleXML, SQLite and whatnot. How many of us felt these are crucial? These features where important, cool, but not crucial, they weren’t enough of a reason for ISPs to upgrade, they weren’t good enough for the “ignorant” 90% user base. Web applications are simple, and that’s what the language, platform and tools are supposed to be. Take a look at Rail’s success then tell me otherwise.

I’m sorry if I sound too harsh, but it is only because I really like PHP and I don’t want it to lose focus. I loved reading this guy and this guy, I used to keep up with [this site]http://www.dotgeek.org and this site, I used to like this board and this thing. I used to do have no doubts about PHP, I don’t want to be disappointed now.

The PHP community is shrinking by the day, at least that’s how I feel. I consider the community to consist of the extremely enthusiastic evangelists, those who make stuff instead of benchmarking them. We have a growing base of young developers who only need a small portion of PHP’s capabilities and a shrinking base of developers who want to make things happen. We need chaos, not community rules. We need a CPAN, not a PEAR, a Smarty or a Zend Framework; these projects give me a feeling of being the “chosen” ones.

However, along with chaos we need an educated community, one that can automatically filter crap. Let a thousand frameworks flourish because with a filtering community only the best of the best will survive, and not because Zend or PHP.net chose that.

Winning company’s acceptance is not an advantage per se. That’s starting at the top of the pyramid, which the opposite of how Perl and Ruby grew. Hackers used to like Perl, I personally love Perl, I use it everyday for tons of mini tasks, and I think that’s how Perl got into big corporates; Larry had nothing much to do with it.

PHP has limited itself to web applications, and that was good. But later on, PHP started to market itself as both an enterprise and a scripting (as in CLI) language. Of course there’s no way it can fit both, because “scripting” and “enterprise” can’t be crammed into the same sentence without horrible consequences. This marketing expansion didn’t come naturally, it felt like it was forced upon PHP and that we’re shoving PHP somewhere it doesn’t belong, and that it was now obliged to compete with two well-backed platforms.

Few have noticed that PHP wasn’t a platform by itself, and that it can’t compete with Java or .NET because it wasn’t complete without LAM. We should be pushing PHP away from that stiff competition and try to convert it to a leader in its own category. I think Marco’s pointing in the right direction with his suggestion to make PHP a foundation. It’ll hand over the steering wheel back to where it belongs.

Aspect oriented programming is a relatively new programming paradigm. The standard example to explain what AOP does for you is the following. Suppose you have a script with a series of functions. Say you want to start and end every function with a call to some logging function:

<?php
   function some_function
   {
      log("some_function: begin");

      /* do whatever the function should do */

      log("some_function: end");
   }
?>

And say you want to do that in each and every function, for example for debugging purposes. It’s a lot of work to do that manually for every function. And when you no longer need it, it is a lot of work to remove it again. This is what’s known as a cross-cutting concern: something you need to implement (in this example, logging), that “cross-cuts” (affects) a lot of code. With AOP, you can write this concern as a single “aspect”. You then run your program through an “aspect weaver”, which will insert the necessary code at the start and end of each function, thus saving you a lot of work.

Well, after proof-reading the article, and (hopefully) getting rid of all the typos and grammatical mistakes, here’s my latest and greatest article; I hope you find it useful.

Blurb (as seen on php|a)

When PHP5 came out, a buzz started about Design Patterns and their application, how to use them, what exactly are “patterns”, and why they are so important. Today, we take a look at one of the famous patterns, the Iterator.

(more…)

Some people at the Apache community are pretty pissed off at how PHP pushes people away from Apache2 although it’s literally the next best thing after 1.3. The reason is obvious, Apache guys want people to use Apache2, PHP guys say don’t. Of course you can say that in thousands of pretty ways, but the fact remains that PHP people (and especially module writers) aren’t paying much attention to Apache2.

But why? Apache2 has all sorts of great features, like threading, filtering, module API, etc. Why not make use of it? I hear you say “If it ain’t broken, don’t fix it”. Well duh, Windows 3.11 wasn’t broken (sort of), OS/2 seemed like a solid system too, heck PHP4 wasn’t broken, it worked, didn’t it? But weren’t they “fixed”?

(more…)

I think we’re all missing the point here, like Marco Tabini said, it doesn’t really matter if PHP is enterprise-ready or not, an enterprise-level company doesn’t care if you’re using PHP or mashed potatoes to get the job done, if the budget allows it then by all means use whatever you want. Nobody’s interested in hearing three-letter buzzword-like acronyms, nobody cares what you’re doing underneath, just as long as you make sure a patient’s heart doesn’t stop, or tons of money aren’t transferred by mistake to Nuke-The-World organization.

Yes, PHP is enterprise-ready, if you want it to be. It can do whatever you want it to do, from messaging, to RPC, to persistence, but are you willing to invest?! Are you willing to develop modules, extensions, APIs and standards? PHP is a monolithic monster, it’s not easily extended, but it still has lots of advantages, lots of potential, but are you willing to invest?!

Developing any project with PHP implies many costs, this includes the learning curve, integration, interoperability, deployment and obviously speed of execution. Each comes with a certain cost, each impacts a project in a different way, and each contributes to moving PHP further into the enterprise market.

(more…)

Well, the new changes in PHP5 are tremendous, and they do bring PHP5 much closer to Java in terms of OO design, except PHP5 isn’t Java, and probably it’ll never be!

What makes PHP compelling to new comers isn’t how it handles OO, it isn’t PEAR, and it certainly isn’t that it can be mixed with HTML code, barely anyone uses that; it’s that it’s easy to pick up compared to other languages, like Perl for instance. If PHP loses this, it won’t be as appealing as it is now, so it’s not in anyone’s benefit for PHP to become, God forbid, Java; we already have one.

PHP is an open-source project, probably not in a way that FSF would define it, but still, you can have the source code, play with it, even compile it and sell it, it’s nobody’s business. This is to PHP’s advantage, and a lot of develops feel somehow secure knowing that even if a company like Sun acquires Zend, they can still fork the whole project and go in separate ways. That doesn’t mean that if Sun does acquire Zend is a necessarily bad thing, it might for PHP’s own good. But the fact that Sun is considered a not-so-open-source by many pro-open source develops, can be disturbing.

I personally agree more with Rasmus’s view on where should PHP go from here, namely to Parrot. It runs better, it’s interoperability with other languages running on Parrot reduces code rewrite, and can easily compete in Java’s market, and probably .NET’s too. I don’t think there’s any there’s any real reason for developers to worry about PHP’s future, we’ll still be able to write scripts and applications in PHP without having to put any commercial threat into much consideration.

Static variables and functions

PHP5 supports both static variables and functions (i.e. do not need an instance to be called), but for some reason, PHP5 doesn’t allow overriding static variables in a subclass:


<?php
class Base
{
    static $var = 4;
}

class Sub extends Base
{
    static $var = 5;
}
?>


Fatal error: Cannot redeclare property static public Base::$var in class Sub in /path/to/script.php on line 13

Interestingly enough, static functions can can be overridden, so the following code would run without any errors:


<?php
class Base
{
    static function func()
    {
         echo “Called from Base\n” ;
    }
}

class Sub extends Base
{
    static function func()
    {
         echo “Called from Sub\n” ;
    }
}

Base::func(); // outputs “Called from Base”
Sub::func(); // outputs “Called from Sub”
?>


Variable class names

Methods cannot be called statically if the class name is stored in a variable, I’m not very sure why, but I’d guess it was too much of a headache to implement. For example:


<?php
class Base
{
    static function func()
    {
         echo “Called from Base\n” ;
    }
}

$class = ‘Base’;
$class::func(); // WRONG!
?>


Would generate:

Parse error: parse error, unexpected T_PAAMAYIM_NEKUDOTAYIM in /path/to/script.php on line 52

The only way to do it is to use call_user_func() or call_user_func_array(). Using the above Base class, this is how func() should be called:


<?php
    call_user_func(array($class, ‘func’));
?>


Same applies to calling class constants, there’s no way to get a class constant with a variable class name without using constant().


<?php
class Base
{
    const BASE_CONST = ‘CONST_VALUE’;
}

$class = ‘Base’ ;
echo $class::BASE_CONST; // WRONG!
echo constant(”$class::BASE_CONST”); // RIGHT
?>


I know that these are some picky stuff, but I still would like PHP to support these, because at the very least, the code would look better.

Now all is left is to actually make use of it, for some weird reason I feel that PHP4 will stick around for a while. Still, expect pains and sleepless upgrade nights, you never know what your boss might say.