Via Sam Ruby I found this awesome presentation about the static analysis of PHP. This kind of action is happening more and more. PHP has some really good things about it, but it is also really rough around the edges. So when smart people take a deep look into the language, and its implementation, it is pretty exciting.

now I have all but given up on PHP (at the moment—I am anything but static) occasionally taking pot-shots from the sideline at what I consider to be silly or misleading statements. That being said, I still do see the beauty of PHP, and I may return to it once again.

Or my mad science project will be successful, and I will have created a wind-mill-destroying monstor!

I'm becoming a bit of a PHP gadfly these days. Seeing as how I am in the middle of building a web server with scheme, it is difficult not to snipe at what some other members in the PHP community are saying about PHP, simply by virtue of seeing things from a different perspective. Now I don't really have it in for PHP (okay, maybe just a little). It is an okay language, and you can really get things done with it. However (and you knew it was coming...)

PHP has one major thing going for it - it's simple nature lets developers keep things simple, and simple is good.

--PHP Developer

PHP is not simple.

PHP's Type System is complex. Sure, dynamic typing is easy, but weak typing is weird. 5 + "10 little piggies" -> 15?

PHP's Object System is complex. It is Javas OO system grafted on top of a really basic system. Ironically, this is where PHPs type System gets so strong to be a real pain in the ass. Ever had to cast an object?

PHP configuration is complex. 3 words: php dot ini.

PHP has complex syntax.

There is also a vast volume of built in functions for php, and an even larger body of extensions. This is not bad (its very good in fact) but it hardly makes the language simple.

There are plenty of reasons to like PHP, but simplicity isn't one of them.

Apparently there was some kind of PHP vs. Javascript fight, to see which language sucked the most. The results? Amazingly Banal, if not downright wrong. There is the list of topics, and their scores:

• Syntax: PHP - Sucks, JS - Sucks Hard
• Data Types: PHP - Sucks, JS - Sucks
• Scope / Namespaces / Packaging: PHP - Annoys, JS - Sucks Hard
• Standard Library: PHP - Sucks, JS - Sucks Hard
• Extension Libraries: PHP - Sucks, JS - Annoys
• Procedural Programming: PHP - Annoys, JS - Annoys
• Object Oriented Programming: PHP - Sucks, JS - Sucks
• Functional Programming: PHP - Blows, JS - OK
• Meta Programming: PHP - OK, JS - OK
• AOP: PHP - OK, JS - OK
• Networking: PHP - OK, JS - Sucks
• Error Handling: PHP - Sucks Hard, JS - Sucks
• Multi Tasking: PHP - OK, JS - Sucks
• Reflection: PHP - OK, JS - Sucks
• Garbage Collection: PHP - Blows, JS - Blows
• Security: PHP - Blows, JS - Sucks
• Garbage Collection: PHP - Blows, JS - Blows
• Security: PHP - Sucks, JS - Sucks
• Tools: PHP - Sucks, JS - Sucks Hard
• Server Side: PHP - OK, JS - Sucks
• Client Side: PHP - Sucks Hard, JS - OK
• Final Rave: PHP - Sucks, JS - Sucks

There are some real problems here...

Syntax: Sucks vs. Sucks Hard

I fail to see how Javascripts Syntax sucks harder then PHP. In fact, in a comparison against syntax, it is a lot like comparing whether dirt from your front garden or your back garden tastes worse. It doesn't matter, it is all dirt. For syntax to be not suck, I think it would have to be more like Scheme, where the syntax is very simple and gets the hell out of your way.

Scope / Namespaces / Packaging

The very idea that PHPs Scope just "Annoys" versus Javascript is laughable. Javascripts scoping is by far superior. Show me a closure in PHP, and then show me one in Javascript, and we will see which one sucks and which one doesn't.

The thing about Lexical Scoping and Closures, is that once you have them, then building packaging and namespaces is not too difficult. In PHP, scope is so horribly broken, that people are yelling about needing namespaces and packages, when if they fixed the scope problem, then these other problems are solved. For free.

Meta Programming: OK vs. OK

Now this I don't get, at all. Meta programming in either language involves using eval, along with string manipulation. This is not 'OK', this is definately on the 'sucks' end of the spectrum. To get an 'OK' in this area, you would at the very least, have low-level scheme-like macros, and be able to work with a data structure related to the parse tree. See Lisp and Scheme macros for a better idea of what OK actually means here.

I (sarcastically) love the idea of using Code Generation as Meta Programming (one of the 'perks' of PHP). Code generation should be your final line of retreat. If you are generating code, you may have lost the battle. It is a good tool to have in the toolbox, but it is not one I like to pull out that often.

AOP: OK vs. OK

Dead. Wrong.

Why? Because to get any reasonable AOP in PHP, you need to install an extension into the language. A fully functional AOP system in Javascript however, is painless and easy to write, what with first class functions and all.

Overall

The PHP slides are a bit of a larf. A language with 3080 built in functions is also easy? A language like PHP has a simple syntax? Umm.... No.

To be fair, Harry Fuecks probably had his work cut out for him. How do you explain the basics of a Closure to an audience who might not know what they are, let alone what you can do with them; all in the span of 60 seconds? (psst, objects are closures with syntatic sugar, but you can't "de-sugar" and object to get a closure). If an audience doesn't understand the idea of a first-class function, how can they understand how easy AOP is in Javascript?

Google's "Summer of Code" has started and they have announced a few PHP projects. Some of them look interesting and useful. However, I am going to pick apart one in particular, that to be honest, looks neither interesting or useful: The PHP Macro Preprocessor. This (as described) sounds exactly like a rewrite of the C preprocessor, which one can work with fairly easily in a PHP environment. To see this duplication of effort on something so boring and useless makes me question just how much PHP is its own language, versus a Frankensteins monster of language clones; see PHP 5's object system for a perfect example.

Now it is one thing to just simply trash the hard work of others and say "you're doing it all wrong!". It is another thing entirely to come up with a different idea. One of the first ideas that I had was to use PHP to preprocess PHP. Lisp and some Scheme implementations already use this process of taking the host language to process the macros in said language. They operate on the code as data first, and then that data becomes the code that is operated on. For Lisp and Scheme it works really well because the code is formatted like one of their key data-types: s-expressions (for an example of sex-pressions, see the sidebar).

Why does the PHP Preprocessor need to be stuck in a world of #ifdefs and #includes? Instead of blindly copying what the C preprocessor does, why not focus on the languages strengths and deficiencies? The object system of PHP needs to be looked at, and see if it can be improved upon through a method of code transformation. Imagine being able to tell your preprocessor that you were writing a facade pattern, and having it fill in 90% of the details, leaving you with the last 10% of implementation. The reason that the PHP community (and similarly the Java community) are so all upon the pattern bandwagon is that both languages lack the facility to gracefully express the patterns in abstracted code; if there was a way for a preprocessor to deal with this deficiency, then a fundamental flaw of the language is fixed. So why not use a subset of PHP to transform PHP? Just as you use PHP to transform an X(HT)ML document, you could use a speedy subset of PHP to transform a PHP document.

The focus on an inline preprocessor is quite limiting as well. All of the processing capabilities are simply skipping over and replacing small sections of code. Why not take a page from the very powerful syntax-rules processor of R5RS Scheme? In fact, its template matching rules would probably make a lot of sense to PHP developers, it is like using a website template in reverse!

Like I said before, my problem with the macro system as described is that it just copies existing functionality from somewhere else without looking at the problem of creating dynamic, maintainable websites quickly; or looking at the issues surrounding macros and meta programming.

Now a Language on top of Scheme that builds PHP applications would be cool.

Rasmus wrote about the "No Framework PHP MVC Framework. And so many people missed the point, it becomes almost funny. First of all, there are a bunch of Ruby on Rails wonks who are obviously dismayed by the entire idea that using a framework, especially one with a central controller could actually be harmful. This is something that Avi and I talked about earlier, albeit in a slightly different content.

Railing on Rails

Probably the most annoying, asinine, and missing-the-point-entirely, is an entire blog post that claims to compare the no framework PHP version with Rails. Look, I am not about to rag on Rails. It is obvious that it does something right and good for a lot of people; in fact, installing and playing with rails is very high up on my todo list.

One of the things that bugs me about this comparison it is at the end of each subsection is a running tally of lines of code written, as if that is the be-all and end-all of programming. If it really had to do with how many lines of code we wrote, we'd all agree that a language like scheme is best, and we'd all program in one language.

But really, the biggest thing is this, I'll just quote the relevant authors, and let them speak for themselves:

I don't have much of a problem with MVC itself. It's the framework baggage that usually comes along with it that I avoid. Parts of frameworks can be useful as long as you can separate the parts out that you need. As for MVC, if you use it carefully, it can be useful in a web application. Just make sure you avoid the temptation of creating a single monolithic controller. A web application by its very nature is a series of small discrete requests. If you send all of your requests through a single controller on a single machine you have just defeated this very important architecture. Discreteness gives you scalability and modularity. You can break large problems up into a series of very small and modular solutions and you can deploy these across as many servers as you like. You need to tie them together to some extent most likely through some backend datastore, but keep them as separate as possible. This means you want your views and controllers very close to each other and you want to keep your controllers as small as possible.

--Rasmus

The controller handles the requests of the user. Every request goes through a controller first. The controller uses the model and view to create a response. In this application, one of the tasks of the controller is to load a list of products, using the model. The controller gives this list to the view, which turns it into HTML.

--Jules

The difference is obvious. Rasmus is talking about why using a monolithic controller might not be a good thing, and shows us how one can get round that using his language of choice. Jules is showing us that his language and framework of choice is so much better then ours because his framework writes all his code for him. Glossing over the fact that Rails itself has, just as a guess, several kilo-lines of code. So I guess that means that PHP is better, because it only took PHP a few hundred lines for what took rails thousands.

Now as I said, I don't have it in for Rails. I don't actually believe that a framework is better then a language for writing web applications. I think both have their place.

Object Fascism

The other funny/annoying part of the comments to Rasmus's blog is the OO-Zealots, another great quote:

I think you are doing a lot of damage with this posting. Do you realize what's going to happen if ONE of the 30 programmers in the building I work in find's your post? For years I have struggled convincing fellow programmer's that PHP is NOT a simple scripting language for the gamers and what not, that it actually CAN compete with J2EE and ASP.NET and C# if used where appropiate. To read this from the creator of the language....I'm still shocked

--Jurgan

Now, at work, I have to deal with a J2EE app. I am not sure if it is a representative sample or not, but let me tell you: if the J2EE/huge-framework method is the right way, then I'll throw my lot in with the bad-guys. Trying to change just one small aspect of this system becomes an exercise in pain. This droplet here, is it configured by the params and oparams in its XML? Or is it configured by its properties sheet? Or is it configured by some other XML configuration file somewhere else? In actual fact, I am also willing to explore the very real possibility that there was a very particular reason for the at-work system being laid out like it is, and I am going to try my very best to learn it as best as I can, without letting my prejudices getting in the way. It isn't going to be easy, but it will be well worthwhile.

Anyway, the central point here is that you can talk till you are blue in the face about how PHP is a perfectly valid language, about how it can be used appropriately, until you are blue in the face. 90% of them will not listen. They don't care. The C# guys spent a fuck-tonne of money becoming certified by Microsoft. They are firmly, and proudly locked in. If they have to admit to the possibility that there is another perfectly valid way of doing things, their house of cards comes crashing to the ground. The same can be said with the Java guys. They love their Bondage and Discipline language, and wear their love proudly. It is so much easier to sneer at a language that challenges what we think of as "good" then it is to actually learn from and learn about that language.

To those guys, I say "So what". Let them spend countless dollars on training and education on broken languages. Go learn Scheme, Haskell or something. Go see what the fuss is about continuations and web programming, so that the next time they start to sneer in your direction, you can retort with something like "Oh, I'm sure glad your language of choice solves every problem. Why aren't we all using Language X for everything? Quick tell the world!". Language advocates are annoying and dumb, and should be treated as such. Don't treat them as people to convince, but people to scorn.

Okay, sorry, this got a little ranty. But language advocates piss me off. There is a big difference between loving a language, and loving a language to the exclusion of all others. I'll finish off by pointing you to this great entry about Java by Steve, titled: Execution in the kingdom of nouns.

Been working with winkiller on optimizing serendipity (the software that runs my blog). Optimizing code is hard work. So far the results are: It is hard work finding what needs to be optimized, and it is even harder work optimizing what can be optimized.

Before I start, a few caveats:

• Most of the numbers here are pulled out of my ass. For instance, the 80/20 rule is invoked. The 8 second load time is the load time it took for s9y to execute on my slow-server.
• I don't really know much about the PHP internals, especially with regards to conditional includes (include_once for instance). All my suggestions from from my understanding of what Rasums says about conditional including.
• Most of this is just guesswork

A few of the things that I have found so far though:

• A large part of the performance problem lies in what I would call the 'sub-resources' of serendipity. The fact that loading the stylesheet and the css loads the entire S9y framework makes a big difference. Optimizing this means re-thinking the dynamic nature of the javascript and stylesheets. It would be the biggest and best optimization S9y could make, but also, the hardest. This would require a break in backwards compatibility. Not a bad thing, but not something to do lightly either. As it stands, if it takes 8 seconds to parse and execute s9y, it takes 32 seconds to actually fully load the front-page of the blog.
• Some performance could be gained in how includes are included. Mostly by removing include_once wherever possible, and using a straight include. (this also counts for conditional includes as well). This would be especially true when using an opcode cache.
• Related, would be how plugin loading and instantiation is handled. The loading of plugins could be handled at the initialization of s9y, again, in a non-conditional manner. Perhaps the best way to do this would be to keep a list of plugin files to load, and on plugin addition or removal, turn the list into a short PHP include that includes the required plugins. The speed increase may be especially significant for users with opcode caches.
• Any other optimizations would be small and numerous, but would have an overall net effect of raising the speed. Sadly, it appears (at least to my untrained eye) that 80% of the code would need to be optimized to gain a 20% speed increase.

In conclusion, the direction of S9y optimization really depends on how S9y is going to handle it sub-resources in the future. If S9y is going to be optimized further, either the sub-resources need to be modified so they do not load the entire monolith that is s9y, or, the 80% of code that I alluded to needs to be optimized, so that we can see a 60% gain. (20% gain, * 3 requests). Obviously it is better to make the sub-resource only take 1 second (for a total of 10 seconds loading the page, 8 for the main s9y, 1 for each sub-resource) rather then make everything load 2 seconds slower (for a total of 18 seconds load time).

John Lim over at PHPEverywhere has a good guide on squeezing code with xdebug.

I have finally pushed through 2 software releases. These have been on the plate for a long time.

Meditation version 0.6

While not a 1.0 release, this is a pretty significant milestone. There are some pretty major changes here. I won't go into all of them, but meditation is really moving twards a true REST API Framework, rather then just a chunk of PHP that is just good HTTP. Some of the features are:

• Processors for HTTP authentication (basic, digest, wsse)
• Procedural Interface for Request Processors
• Request Entity Parsers, meditation can now handle Request Entities of any type, as long as you build the Content Handler for it.
• Handles HTTP Method over-riding through request parameters (http header, query string, etc.) via X-Rest-Method.
• A new Gate Persistor was built (SqlGatePersistor), while it is still abstract, it fills in most of the details. MySQL, PostGreSQL, or Oracle based persistance mechanisms should be easy to build on top.
• General Code Cleanup

So... there ya go. Go and download, and tell me what you think!

DokuMintTea version 0.1.1

A PHP API Documentation Generator, that outputs to DokuWiki Pages. This project was highly coupled with meditation, but a significant portion of that coupling has been removed. Finally DokuMintTea can start to stand on its own 2 shakey legs. A very Alpha quality release, but a cool documentation project regardless. The biggest features are:

• Uses the built in PHP reflection classes, so that most of the attributes of your code are taken from your code... no more @public, @private or other assorted crap.
• A slim set of @directives.
• Outputs to dokuwiki syntax and therefore you can embed wikilinks, code, or lists right into the comments. Because wiki syntax mostly looks nice, it looks good in both places.

Update: I kinda botched the 0.1 package, and packaged DokuMintTea with debugging turned on, which means it wouldn't write the wiki pages, but send them to stdout instead. its fixed now. Sorry bout that.