On PHP Debuggers

[The views expressed in this blog are definitely my own and not those of anyone I work for, have worked for, or even get drunk with.]

I’m used to Xdebug. We use Zend Platform. Am I going to have to have a Rodney King moment?

Here is Derek’s take on it, and here is some guy from Eclipse PHP IDE’s response.

I don’t care.

I want the developers here to use the development environment they want and me to use the debugger/profiler I want. Anyone know a solution? Currently it seems that if I use Zend Platform, we have to use Zend Studio or Eclipse PDT to debug. If I use DBGp, we can use ActiveState Komodo, NuSphere PhpED, or PHPeclipse.

Am I wrong? Are there other editors that support DBGp? Which should I use (in particular I want have valgrind for profiling output and I like the built in error system in XDebug, but I haven’t had a chance to delve into Zend Platform so you can try to sell me on that).

[Other rants after the jump]

I call bullshit

Okay, let’s be Frank (not Derek or Guy).

The binary protocol thing is bullshit. Honestly, this is debugging, how much shit is going down the wire here?

PHP serialized data is bullshit too. We’re developers and you are developers. It’s not all that hard to parse XML anymore.

Language-specific protocols aren’t any better than general ones unless they’re provably better. You’re going to have to prove that. I call bullshit on that.

I call bullshit on the session initialization over the URL being a bad thing. We’re going to be debugging on protected development and staging servers and are not going to be live debugging either system on the 80 or so web servers we have here. It’s a good idea and proxy servers aren’t as convenient.

“Can’t we all just get along?”

I agree with Lukas. (Though Lukas’s article was too early to note that the Zend debug protocol is now published.)

I don’t understand how it would be that hard for any PHP-based IDE to support both protocols now that they are documented.

The real reason

Let’s be me. Terry: PHP guy in the trenches who says things other people don’t have the balls to say. You know, Mr. foot-in-mouth. These are just theories from my perspective.

The reason PDT for Eclipse doesn’t support DBGp is because Zend supports PDT and Zend doesn’t use DBGp.

The reason Zend doesn’t want to use DBGp is because it isn’t a PHP-specific protocol. Look at Zend’s product line, it is, hands down, the best toolchain for PHP development out there. But…

Anyone who has programmed Java knows that this wouldn’t survive if JVM were the execution layer instead of Zend Engine and we could use the IDEs from the Java world. Anyone who has used Visual Studio knows something similar would apply if CLR replaced Zend Engine. As for Parrot—the money is in enterprise tools and support not as an open-source tool developer and that wouldn’t play well for Zend to be “just a” instead of “the” PHP company. And yet all those are JITs which would kick Zend Core’s ass if they could just do PHP.

I mean it’s bad enough that PHP6 is going to use APC as code-caching. But an open debugger? The horror!

(Of course, the fact that I don’t develop using an IDE and prefer to use develop in PHP should be some indicator that this is moot. Honestly, PHP isn’t going to win awards for speed and IDEs that do refactor-assist here—that’s not why smart developers use this language.)

The reason Komodo doesn’t support Zend’s debug api is because Komodo isn’t just a PHP IDE. (Okay, Shane is off the hook.) But is it really hard for XDebug to implement a layer to support Zend’s protocol, Derek? Many developers already use Zend Studio, and I like your XDebug. As far as I’m concerned Zend Platform is just a convenient way of getting PHP up and running with code caching and compiler optimization.

That’s my opinion. Feel free to prove me wrong. I don’t really care except that this shit is keeping me and the developers here from getting their shit done.

And talking about Java…

Going back to Lukas’s article I was amused by all the attempts by some people with huge chips on their shoulder to steer the conversation toward Java. Lukas is a PHP developer talking about PHP debugging and your solution to everything is to “Java ru1eZ U PHP boyz.”

Too bad they assume that there aren’t PHP developers who don’t know Java, look toward the Java world, or respect the ideas there, or have a healthy dose of humility about what goes on there. The difference is we take what we need (or are able to take) and don’t pretend Zend’s tools are as refined as IBM’s. On the other hand, we don’t pretend that we are a better way of solving the web problem—we know it. That’s why the list of consumer-facing internet websites are a mile long and their metrics are so large that I drown in a wealth of “in your face” examples: Yahoo!, Wikipedia, WordPress, SugarCRM, Digg, Flickr…” Ouch!

Maybe if you tried to figure out why those guy chose PHP instead of lecturing us that we all should be using J2EE (because of hibernate, struts, servelets, jsp connection pooling, or whatever flavor-of-the-month you’re spouting this week), you’d figure out why I’m laughing at you right now.

And talking about Zend…

Hmm, I thought I was the only guy who was allowed to piss on Zend?

(Speaking of which, I said I would speak there only if you asked everyone else you did the same thing too and offered them a my spot to them. You assured me there was nobody else, but there was one other you did it to. I found out this at the conference. Hint: the person trumps me.)

So let me correct a few things from Lukas’s commentariat.

First, Zend Framework is BSD licensed. It’s not embrace, extend, and destroy. My trepidation with using it has nothing to do with the license and people shouldn’t spread that sort of FUD around, that sort of thing hurts all the developers who created, promote, and use ZF. Even if I have my reasons for being none of those people.

Second, Zend Core may be closed-source, but Zend Engine is not. Some of you are confusing the two. Back in the old days, Zend Core didn’t include the full compile and was called Zend Optimizer and Zend Accelerator. We didn’t cry that that shit wasn’t in PHP and we were too cheap to pay. Take a look at where PHP is going with 6 before you fear that the PHP world, for one, is welcoming our new Zend overlords.

I’m not a Zend fan (just ask anyone at Zend). But look what they do. If you want to prevent them from making a buck, take off the tin foil hat and try to compete with them instead of spreading lies you’ve been told. Personally, I feel that skirmishing with the Java zealots is only fun when they venture into my field of expertise where I can bitch slap them back home to their starship enterprise.

Live long and prosper, biatch!

2 thoughts on “On PHP Debuggers

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.