There are probably more than a few naive programmers who would read results like this and start to avoid these constructs in their own code for performance reasons. These are the same kinds of people obsessing over a few single or double quotes, who eschew “slow” objects in favor of switch statements that are many times slower than the polymorphic method calls they are trying to avoid.

But, that’s not the end of the story. Larry ran his benchmarks using 2,000,000 iterations. The N really matters here. Sure, iterators are slower than arrays, but you aren’t going to be iterating over two million things. I tend to fetch my database records in lots of 25 or 50. You aren’t going to be making two million invocations of __call. But how many will you make? Under what value of N does the performance of these techniques cease to matter? Is it ten, one hundred, one thousand, or ten thousand? You may be surprised at how few calls your program actually does and how little impact it has on performance.

As Wez and Travis point out in their comments, profiling is the way to find out the potential impact and to discover your true N.

Paul M. Jones has a good example of what I’m talking about. There, call_user_func_array appears to be a bottleneck, but it turns out that its the function being called, htmlspecialchars, not the calling process that consumes the balance of the time. In that case, the function was “only” called 300 times. I find that order of magnitude to be fairly typical. Something to be aware of, perhaps, but not something to obsess over.

The scale that Cal is talking about is actually better known as modularity:


| Few large modules ---- Sanity? ---- Many Small Modules |


If you haven’t listened to Alan Kay talk about the benefits of many small modules, you should do so now. Alan Kay coined the term Object Oriented. Love OO or hate OO, if you have an opinion on it, you should know what he was thinking. Hint, it wasn’t C++.

On the other end of the scale, One Giant Function is generally known as Big ball of Mud(PDF) Here is Brian Foote’s presentation on the paper (read the paper first).

 
function set($name, $value);
function get($name);
 

Some times there are some ancillary methods to deal with unsetting, checking for existence, setting via an array, or dealing with references in PHP 4. They can really clutter up the definition of a class. That’s not good. All this code is fairly standard, too, but it gets duplicated on every class that does this. That’s not good, either.

Oh, I’ll solve this problem by making a base class, some may say. Wrong. This a very feeble reason to spend your one shot at inheritance. Trust me, I know, I’ve done it.

I think the idea is to make the class extensible. But PHP is really ok with just setting new properties on a class.

 
$obj->foo = 'bar';
 

Another variation of this pattern is to use setXXX($name, $value) or setYYY($name, $value) methods. This happens alot with “options” or “vars” or “properties.” It also happens on request wrapper classes. To me this looks like there is an object here just begging to get out for each XXX and YYY.

 
$obj->xxx->prop = 'foo';
$obj->yyy->prop = 'foo';
$obj->zzz->prop = 'foo';
 

Since I’ve started eliminating these in my own code in favor of direct properties, intermediate objects or __set and __get, I feel I’ve seen nothing but positive results. Try it. You may like it, too. Let your properties be properties.

UPDATE:
From reading the comments, I think there was some confusion about what I meant in this post. I am not talking about using naked properties instead of accessor methods. I’m not talking about accessor methods at all in this post. A specific accessor method, such as

$obj->getFoo()

$obj->get('foo');

Even on projects with extensive generated documentation, I find that kind of documentation to be of extremely low value. The problem with inline API documentation is that there is no sense of priority. Developers are encouraged to document every element that can possibly be documented. Then, when the documentation is generated, there is no way to distinguish the important from noise.

Another problem is restating the obvious. When a property or method really is well named, there may not be much more to say in the docblock. But, the mechanics of docblocks invites the programmer to say it anyway. So, you end up with comments like “$widget the widget.”

Duplication is also a significant problem. If you inherit from a base class or you implement an interface, there is a tendency to copy and paste the doc block from the parent to the children. This is an obvious maintenance problem. In fact, this is one of the major problems with comments. If comments restate what the code does, its a form of code duplication. When the code is changed, it requires changes in the comments. In this sense, comments make code harder to maintain.

Lately, I’ve been trying to curb the attractive nuisance aspect of docblock comments by replacing docblocks with comments like

 
// Definition in parent
 

 
// docblock intentionally omitted.
 

Well, if docblocks are so bad, what is the alternative? Well, I’ve tried a few, including using a wiki for API documentation. Here is the problem. If duplication between the comment and the code is created by inline documentation, that maintenance problem becomes significantly worse with distance. If the documentation is external to the code, that distance really harms the ability to keep the documentation in sync with the code. So, docblocks are bad, but everything else is worse.

Docblocks were popularized by Sun and Java (or maybe Donald Knuth). But when sun was documenting their Java APIs with docblocks, they had a professional documentation team to do the work. When teams that don’t have a dedicated documenter role use these tools, I think they fall short.

So what is the solution? I’d like to see better techniques and conventions for solving the problems of docblocks: avoiding duplication, avoiding restating the obvious, and avoiding the tendency to docblock everything thats docblockable. Maybe there are more successful documenters out there who are handling these API documentation anti-patterns better than I am. I’d sure like to hear how.

Technical Background

A team needs members with a technical background. These guys are the ones that ensure everything works. They can write the hard bits of code, keep everything performing and make sure the code is maintainable. Without these guys, you will have problems. On the other hand, sometimes those with a technical background view problems solving as a puzzle, where the solution is the end in itself.
In my experience, team members with a less technical background are more empathic toward the user community. They view problem solving as a means to a goal. A customer focus is what makes a project successful. Software can be successful despite technical problems, but it cannot be successful if doesn’t meet the customer’s needs. Having some non-technical people helps prevent your resident technocrats from building a system that will service 10,000 concurrent users, but doesn’t meet the needs of the 329 users you have today.
Perhaps at the extreme end of this spectrum is the extreme programming practice of including a customer on the development team.

Experience

In expert versus novice programmers, I make the distinction between skill level and experience. Age, skill and experience often correlate, but not always. Your young apprentice programmers are important to have on a team. They can react faster. Sometimes not knowing better is a bonus. They’ll do things more senior team members don’t want to do. They do things they’re not supposed to do, sometimes for the benefit of the team.
I think people underestimate how long it takes to actually become an expert, as I mention in my previous post. But, then they also underestimate how similar all software projects are. They also overestimate the impact of their toolset. Generally the technologies in the laundry lists that form most job listings are not the critical success factors for that project.
People want a programmer with who can hit the ground running, who is familiar with all of the teams tools, languages and libraries. But, this is a monoculture as well. Sometimes you need people who aren’t from your toolset culture to point out where you have swallowed the hook too deeply or to introduce new tools and techniques from their alternate background. Sometimes their learning process can teach you something.
While some experience is valued in programmers, age sometimes isn’t. However, you need the older, more stable people as well. They keep the young ones from repeating the mistakes of the past. They keep the project on an even keel. It helps to have an older perspective on the team. I think they help keep attention focused on what matters. The tension between the older and younger team members helps keep the team on track.

Traditional Diversity Factors

I have no opinion on the impact of race. I have an opinion about women on software teams. I wish there were more of them. I have worked on software development teams with diverse nationalities. I regard that experience as positive. Different cultures have different tolerances for risk, different respect for authority or tradition. I think cultural diversity on a team is a good thing.

Managing Diversity

Over the years, there have been many methods proposed of matching people with the jobs they are best at. The solution that works best is to ask them. People gravitate toward the tasks that require their special skill sets. Good team management means hiring diversely and allowing that migration. On a well managed, diverse team, people will self select the jobs they are best at. As a result, the diverse team is more resilient and I believe potentially more successful.

BBCODE was designed for this purpose. There is no actual standard, but the core syntax seems fairly uniform. It’s good for those used to forums, where it seems to norm.

HTML markup is nice because it is a standard, even if varying subsets are supported. Learning a little HTML isn’t going to hurt anyone, at least for the next 20 years or so. The problem is that HTML was never intended to be hand edited. The syntax is not the most inviting, and different HTML-like markup languages handle whitespace differently than the HTML standard.

Wiki markup syntaxes were designed to be human friendly. The main problem I have with wiki syntax is that there is no standard. It seems like every wiki has a different way to formulate a link, for example. I guess there is some progress with Wiki Creole, but I still have a bad taste in my mouth.

The other problem I have with wiki markup is that I find it to be non-deterministic. When I edit any given wiki and try to use more than basic formatting, I never know what I am going to get. Most of the markup processing engines for these wikis are impenetrable morasses of regular expressions. It can be hard to gauge interactions. Are you really sure they are secure?

Speaking of impenetrable morasses of regular expressions, have you ever looked at WordPress’s input path? I’m sure every one with a WordPress blog who likes to blog about PHP code knows that it is a code eater. I’ve been particularly disappointed with WordPress in this area. Most the “code formatting” plugins still have problems protecting code from WordPress’ heavy hand.

But the WordPress preg_replace gauntlet doesn’t just mangle code. I have a post which has been sitting in draft mode for several weeks because I can’t figure out how to give it the proper markup. WordPress is somehow taking my perfectly balanced input markup and producing “unbalanced” output markup. I haven’t yet tracked down the problem to either submit a fix or to do a good bug report. Frankly, I’m not looking forward to trudging through all those regular expressions.

In Chris’ post, he takes the regular expression approach. Folks in the comments have pointed out a few problems with his approach, including the problem of interleaved tags. If you can’t tell by now, I am not a fan of the regular expression gauntlet approach to markup languages. I prefer a defined syntax and a traditional computer science style parser (which may use regular expressions).

The other must-have is a preview option. With so much variation in markup languages, not having a preview leaves the user to play Russian roulette with their submitted content. I’ve talked about that before in the usability of input filtering. This is another area where WordPress leaves the user high and dry.

The complex input path in WordPress combined with its reliance on global variables seems to leave it unable to do an in-page preview. The admin area preview is an IFRAME so that it launches a separate request. The various live preview plugins are JavaScript based and don’t work when it is disabled. They also don’t pass the input through the same input path that WordPress uses, so they are not a true preview.

I don’t mean for this to be a WordPress rant, on the whole, I like WordPress. Rather, I just wanted to point out how hard it can be to do good input filtering, that is safe, reliable, deterministic, and usable.

I have a great fondness and respect for the old Object Pascal based Delphi. Delphi’s VCL has been influential, inspiring the GUI components in Java. And, of course Ander Heijlsberg went on to put a huge stamp on C# and .NET that would be familiar to any Delphi programmers.

I’ve always admired this approach of extending the language syntax to make common things easy and for the integration between the language and the tools. In Delphi, this was evidenced by the excellent properties support. Six years later, this is the feature I miss the most in PHP. This language extension approach has seen its culmination in C# and LINQ. It almost pains me to say it, but the cutting edge of commercial language design is at Microsoft now.

On the other hand, I’ve never had that much respect for Borland as a company. We were big enough to have Borland representative’s come to our office and try sell us their products. They were terrible at the mechanics of selling into big companies. I was in their beta programs. I went to their conferences. I’ve never had any sense that they know what they are doing business wise. Inprise? What were they thinking? Now here they are, just having gotten their asses kicked by eclipse in the Java IDE space and what are they working on? They release an IDE for PHP, just as Zend is embracing Eclipse in the PHP space. Brilliant!

I don’t quite know what Delphi means now. To me, its always been and IDE plus Object Pascal. What is it now? I also don’t quite know what Borland has become. Is it CodeGear now? I guess that the Delphi for PHP IDE comes from Quadram and their now discontinued QStudio product. And the VCL is their WCL (no linkage found). Anytime I’ve been touched by the corporate entity that was Borland, confusion ensued. I’m confused now.

It appears that the PHP version of the VCL will be released on open source. There is nothing at the sourceforge project, yet, but I’ll be interested to see what it looks like, if only for old times sake.

The Delphi tool approach was to serialize an object based representation of an application, then offer tools to create that serialized representation, and to load that representation at run time. In Delphi, that serialization was done into the form files (.DFM). I’ll be interested to see how Delphi for PHP does it. Perhaps, this is an area where the Eclipse PHP Development Tool can learn. I know that I definitely had Delphi in mind when I was writing my column on Object Serialization for this month’s php | Architect.

Meanwhile, if you want to see the Delphi influence in PHP with code that you can download today, take a look at the Prado framework, which I imagine to be like the VCL for PHP, but without the supporting IDE.

This is a space I’ll definitely be watching.

However, OOP is not on the decline. Quite simply, it has become mature. The discussion may be on the decline because almost every language that anyone actually uses implements a core set of OOP features. OOP has won its arguments. Good luck taking a language mainstream without it.

Oh, yeah, there are some OOP features that are still controversial or unusual. There is the single versus multiple inheritance debate, or perhaps Ruby’s open classes. But, I think these things have a way of cross-pollinating across the popular languages when they make sense.

A good example of this cross-pollination is happening now with properties, accessor methods and the uniform access principle. Language support for declared accessor method is slowly creeping across all of the major languages. Not that Objective C is all that popular, but Objective C 2.0 adds support for ‘em. Even stodgy old Java is considering language level property support.

Sadly, PHP does not yet have language support for declared properties with accessor methods. What are __get and __set? They’re property missing handlers, not accessor methods. You can simulate accessor methods with them, but that is a poor solution for most applications. There is no way to support differing visibility, for example protected setters and public getters. Property not found handlers are prohibitively verbose to write, have a poor performance profile, have no capability for reflection, cause interoperability problems, and have inheritance edge case gotchas (not present in the java beans model, for example). My hope is to see good language support for properties in PHP 6.

Closures may not be object oriented, but they seem to be undergoing that same language cross-pollination. Thats seems to be a pretty good sign that they are useful. It doesn’t have to be closures OR objects, it can be closures AND objects. We can use each when they make sense.

Closures are another wish list item for PHP 6. PHP is almost wired for them with its callback psuedo type. Everywhere you can use a callback in PHP, you could use a closure. I’d like to see the callback Pinocchio become a real boy like integer or boolean. The cool thing is that with PHP’s weak typing the string and array forms of the callback pseudo-type can automatically be converted to a native closure type when needed.

As I said, the core OOP features that most programmers use are in all the mainstream languages. The interesting part is how they handle the OOP edge cases. This is the space where the framework developers live. As I wrote in culture of objects, PHP has some problems here. In some ways I think Ruby’s support for edge cases is exactly what allow a framework such as rails to be built in it, although, I’m not familiar enough with Ruby to say for certain.

I think addressing some of these issues in PHP 6 will make it a Ruby killer for web applications. It isn’t necessary to be perfect here, just to be good enough and allow the larger community, distribution, and stability to take over. Unfortunately, there is a long lead time here. If PHP 6 were to add support for declared accessor methods, closures, and late static binding — my top three framework enablers — it would still be at least 2-3 years before PHP 6 was sufficiently deployed and the frameworks could adapt to the new features.

In the meantime, while the PHP culture may have problems, the Ruby culture may not be without its own problems. The influx of lisp and smalltalk programmers, two languages that did not go “mainstream” may prevent Ruby from going mainstream. Take a look at The impending ruby fracture. Isn’t this one of the things that happened to SmallTalk and Lisp? I’m still not convinced that Ruby hasn’t inherited many of the same maintenance problems from its Perl heritage. Just like english, huh? Only time will reveal Ruby’s maintenance characteristics. I give it about 2 to 3 years for today’s Rails systems to hit full legacy mode. How long do you think it will take for top notch unicode support in Ruby?

Obviously PHP 6 is all about teh unicode. Including an opcode cache is going to be an important performance and adoption driver. However, I’d like to see more progress on framework enablers. I really want to see these in the next major PHP deployment cycle and not in the PHP 7 deployment cycle. Are there framework enablers other than closures, declared property accessors and late static binding that I have overlooked?

I have high hopes for PHP 6 as a mature and mainstream language.

My Grandma is doing well. They used an experimental new procedure called radio frequency ablation to remove the meta-static colon cancer tumors from her lungs. This procedure is amazing compared to the standard treatment. The doctors at the University of Michigan were impressive. We’ll know the results in a couple months when her lungs look a little less like scrambled eggs. We’re hopeful.

I’m not much for retrospectives. Looking forward into 2007, I have a few major goals. I joined a gym today. I’m going to get a new laptop and refresh my development environment next week after MacWorld. I want to get at least a beta release of WACT out by May. I have to prepare for php|tek. I need to find a new place to live by this fall. (Ann Arbor?) I want to move by the end of the year.

I loved all my christmas and birthday gifts this year. (My birthday is December 28th.) This year I pointed everyone to my Amazon.com wishlist and I ended up with a ton of good books to read. Jason Gillmore from Apress also sent me some web development books. My to-read stack for 2007 includes:

• The Promise of Sleep - A survey of the subject of sleep for laymen, written by a top sleep researcher. I’m almost done with this one. This book has a bunch of sleep deprivation horror stories and a good survey of what is known about sleep, which is not much. Its incredible that we know so little about something we spend so much time doing. Its also amazing how many people have easily treatable sleep disorders that don’t even know it. Do you snore?
• Don’t make me Think - Looks like a nice overview book on web usability.
• Domain Driven Design - Recommended by Jason and Marcus. How did I get this far without reading this book?
• Da Vinci Code - Wasn’t on my wishlist, but I’ll read it anyway. I read so little fiction these days. Where is a beach when you need one?
• Getting Things Done - I’m almost through this one. It is a testimony to the power of the ideas that this book expresses that so many people recommend it, despite its being so incredibly dull. Useful? Yes. Inspiring? No. But, then I’ve read enough of these self help / personal productivity type books for a lifetime. Anyone want to buy a Franklin Planner? I used mine until I got a cell phone.
• Practical Subversion - I’m really liking subversion. If you haven’t tried it, do so. I’m hoping to combine this with Greg Beaver’s book, The PEAR installer manifesto — the book on my wishlist I most wanted that I didn’t get, to create a new deployment process.
• Pro CSS Techniques - A CSS book that tackles maintainability? I’m really looking forward to this one.
• Pro MySQL - The last MySQL book I read was a couple years ago, yet I use it almost every day. I’m due for a refresh. This one looks good.
• Pro PHP Security - Never hurts to brush up. This one looks like it has alot on encryption, SSL and SSH; not strong areas for me.
• Pattern-Oriented Software ARchitecture Volume 2 - The first volume, A system of patterns, is one of my “always within reach when developing” books. Nice to add to the set.

Thanks for the books, guys. I’ll have in-depth reviews of some of these here in the future.

Happy New Year.

This is not a surprising ranking. After all, Tim is from Sun, and the maintainability complaint is common in Anti-PHP rants. I’m not trying to suggest that Tim is anti-PHP, far from it, it seems. I’m just using his ranking as a spring board to ask questions.

Chances are that your average Java jockey or C scientist’s first exposure to PHP is to download one of the popular PHP applications. These are usually the product of some open source mega-project with developers of varying degrees of skill. Our engineer-by-day spends a few evenings with the program. The code is not technically outstanding.

How can something like this be so popular he asks? Yet, the software is successful by definition. Nobody downloads unsuccessful open source applications. The technocrat, heavily invested in his own technical prowess, faced with successful yet technically inferior code experiences cognitive dissonance. The only thing to do is to belittle the successful, but surely offensive code. “I could write better code than this,” he says, or “this code sucks,” or “this is unmaintainable.”

It is easy to dismiss these gripes inside the PHP community. After all, those of us using PHP professionally can write maintainable code in PHP. Ask any programmer and they will tell you, “My code is maintainable.” Who writes all of this unmaintainable code, anyway?

Lets take this gripe at face value for a moment. Why is PHP code considered hard to maintain? Is it the language that produces code that is hard to maintain, or is it that the popular ambassadors of the language happen to be programs that are hard to maintain?

Another common PHP sucks complaint is that PHP doesn’t scale. When you are talking about traffic, there are all sorts of counter examples for this. Personally, I’m dying to learn the story behind those .php extensions on YouTube. But, this post is not about requests per second.

Another kind of scalability is team size. I think that when some people complain that PHP doesn’t scale, what they mean is that PHP doesn’t scale to large development teams or large projects. Now we are back to the maintainability issue.

What is it about PHP that makes people think that it is not suitable for larger development teams?

The criticisms of maintainability and scalability generally come from outside the PHP community. But, there is a common complaint from within the PHP community.

It is hard to find a PHP wish list that doesn’t include namespaces. It comes up again and again.

Sometimes users request a feature without explicitly making their true desires and intentions known. They say “I want feature X,” but what they really mean is “solve problem Y.” Good programmers can hear the request for X, but make the jump to solving Y.

When people ask for the namespace feature, the problem they want to solve is integrating code from multiple parties. I wonder if the frequency of this request is a signal of a problem in this department? Perhaps one that requires more than just namespaces to solve? Is the namespace request a proxy for a larger problem?

What is it about PHP that makes it hard to integrate code written by multiple parties, whether they be different developers or different organizations?