Chad Perrin: SOB

27 March 2007

Buggering off

Filed under: Geek,Metalog — ???? @ 06:01

Many thanks to apotheon for letting me guest blog over the last several days.

I didn’t get anything (besides this) posted today because I was too busy debugging PHP. Man, I need to find some better debugging tools for that language/platform. The best I can come up with is to insert “echo” statements that end up all over the page. Anyone have better ideas?

I hope I’m not permanently banned from SOB for saying so, but ASP.NET with Visual Studio addresses the web app debugger problem far better, and I can’t say that debuggers are any less required for PHP as a language. Ruby, on the other hand, doesn’t seem to need debuggers. Maybe that’s because that language and the Rails framework actually make sense.

How do you debug the server side of web applications?


  1. I hope I’m not permanently banned from SOB for saying so, but ASP.NET with Visual Studio addresses the web app debugger problem far better [than echo statements]

    Banned? Perish the thought. I’m an equal opportunity loather of technological stupidities, and if asked I have some harsh things to say about Perl’s issues re: OOP and dereferencing syntax (despite liking Perl generally quite a bit). I certainly won’t argue that PHP is in desperate need of a worthwhile debugger — or that VS.NET provides passable debugging capability for ASP.NET, for that matter.

    All in all, I’m thrilled with the results of asking you to guest-blog here at SOB. I’ll probably say something about that in my first post after my return — which will probably have to wait for tomorrow, alas.

    By the way, I tend to debug PHP by refactoring as though it was working code that could use some reorganization, and testing the parts’ operation. It’s the only sane way I’ve discovered of debugging any PHP more complex than a set of require() statements.

    Comment by apotheon — 27 March 2007 @ 06:25

  2. Heh. I have never found a better debugging system for PHP than echo statements. On the same page, that is about as good as it gets with Perl, too. Although I will say, with Perl I can use Perl Builder from Solution Soft ( It is buggy as all get out, but it is better than nothing. It is reason #4,124 I say that PHP is doomed, and why Perl is doomed. What programmer in their right mind wants to be using the same debugging techniques we were using in 1983? I sure as heck don’t. And you are right, the debugger in Visual Studio is the best game in town, as far as a Web app goes. Chad can call it “passable” if he wants to. It is not “passable”, it is extremely good.

    The really depressing part of all of this, is that I do not care how good you are at writing in a particular language, if debugging in it takes ten times longer than it should do to the tool quality, any efficiency gains you made from your super whiz bang language (and PHP hardly qualifies as “whiz bang”) are lost to the lack of a debugger.

    And I think that your guest blogging is just fine. :)


    Comment by Justin James — 27 March 2007 @ 06:54

  3. On a side note, I am very curious how the “CCD CopyWrite” applies to comments that other people leave on the posts… on the one hand, you own the board, and could have users agree to a TOS whoich would include signing all legal rights over. On the other hand, without such notice or TOS, I legally own the copyright to my own comments, since I create them. Therefore, any page which contains my comments (or anyone else’s) automatically invalidates the “CCD Copy Write” in the absense of a TOS. Not a complaint per se, but just one of those “out of the blue” thoughts that I thought you guys would find interesting.


    Comment by Justin James — 27 March 2007 @ 06:58

  4. […] Sterling Camden subbing for Apotheon: I hope I’m not permanently banned from SOB for saying so, but ASP.NET with Visual Studio addresses the web app debugger problem far better, and I can’t say that debuggers are any less required for PHP as a language. Ruby, on the other hand, doesn’t seem to need debuggers. Maybe that’s because that language and the Rails framework actually make sense. […]

    Pingback by Labnotes » Inverse Learning Curve — 27 March 2007 @ 08:56

  5. Thanks, guys.

    Well, in a way I’m relieved that I haven’t been spinning my wheels when better tools are available. It’s so easy to make mistakes in PHP that the lack of a debugger makes it painful to create anything meaningful. But Justin, I really don’t miss having a debugger in Ruby. That’s a “whiz bang language” for you.

    That’s an excellent approach, apotheon, and now that I’ve been hacking at it the code really does need refactoring. Of course, right now the biggest problem I’m facing has nothing to do with PHP and everything to do with CSS.

    Comment by SterlingCamden — 28 March 2007 @ 09:47

  6. Justin James:

    Actually, Perl provides excellent debugging facilities, and very good exception handling to boot. If you’re using it on MS Windows, you may lack some of that — I really don’t know. On unixy systems, however, you may want to have a look at the contents of man perldebug. Add to this the lifesaving strict and warnings pragmas, and you actually have access to debugging capabilities that I often wish I had in other languages that come with more traditional IDE-style debuggers.

    It’s all certainly a lot more useful than gdb has proved to be for me, in the past.

    re: copyright . . .

    I had a more explicit notice of copyright just above the comment box at one time. I’m not sure what happened to it. It’s also arguable in court that when you submit original content to someone else’s website, you’re essentially assigning a non-exclusive license to do whatever the hell the recipient-site’s “owner” wants to do with it.

    I suppose if you really want to press the issue, I could just delete all your comments. In the meantime, I’ll see about adding that copyright notice back in. I refuse to be held hostage by someone else’s ridiculous copyright claims.

    Comment by apotheon — 30 March 2007 @ 03:42

  7. Unfortunately, the huge majority of my Perl work has been done in a CGI environment, and that is where the “Perl has poor debugging tools” comes into play. To make it worse, I traditionally was writing the code on a local Windows machine, but deploying via FTP to a remote UNIX machine (you’ve gotta love not having shell access). I suppose under those circumstances, any language needs to rely upon dumping output to a log file or printing to HTML comments to provide debugging information. That being said, Visual Studio is, bar none, the best system for debugging Web applications that I have ever used.

    On the copyright thing… no way would I ever push on that, it was just one of those interesting musings that popped into my head, and I knew that copyright is one of your areas of interest. You are right those, it could be argued that the act of posting to a Web site proabably implicitly grants some sort of rights, but which ones, I do not know. I am not a lawyer, as it were. Although I should be one…


    Comment by Justin James — 31 March 2007 @ 06:23

  8. I see what you mean about debugging CGI, et cetera — you can only debug stuff so much outside of the actual deployment environment before you have to figure out how to debug it in production deployment (or at least an identical environment). When you don’t have shell access on the machine in question, that typically implies that you don’t know much about the deployment environment, which just makes things even more interesting sometimes.

    As debuggers in general go, Visual Studio’s is kinda middling, in my experience. As far as debuggers for web development — that’s another story. I’ve never really had full-on debugging tools for environments where I don’t have direct shell access, so I guess maybe VS is pretty good under those circumstances. Then again, since I’ve never used VS for web development, I don’t know for sure. I thought we were just talking about debuggers in general, at first.

    re: lawyers and copyright . . .

    I’m no lawyer either, though it increasingly seems we all have to have a pseudo-lawyer hat just to perform our day-to-day jobs. It’s downright silly. If we’d just get rid of this copyright crap altogether, that would basically go away. Le sigh.

    Oh, well, back to reality.

    Comment by apotheon — 31 March 2007 @ 05:50

  9. Development environment vs. production environment issues: reason #5,987 why I cannot stand Web development. Debugging difficulties: reason #19 why I hate Web development. It is flat out rediculous. As far as I know, Visual Studio is the only tool that hosts the Web/application server process within itself and hooks directly to it for debugging. Eclipse might do it, but while I have installed Eclipse, I have never used it. The installation was enough effort for me!

    Don’t even get me started on the need to be a lawyer to do my job… it seems like all of our “subject matter experts” are simply human bookmark files. The send me a bunch of URLs to government Web sites as their “expert” help. Funny, it was up to me to discover all of the gotchas in my latest project while the “expert” was hung up on whether things should be drop downs or radio buttons. I keep begging for direct access to a technical lawyer, like a Lawrence Lessig type or something, maybe Judge Penfield Jackson (I think that was his name). Ah well, I need to rest, too little time, and I get to test the mess made by Windows patches on our application tomorrow morning..


    Comment by Justin James — 31 March 2007 @ 10:09

  10. The only issue I have with Visual Studio is that it has so many features that it’s too slow. Like taking a cruise ship from San Francisco to Oakland. But it’s very nice at being able to examine variables and step through code running on the client and on the server, seamlessly.

    My only experience debugging Perl on the web was CGI, for which I created my own crude debugging tool. Back then, by default I couldn’t even get error information back from the server — you’d just get a page load error.

    Comment by SterlingCamden — 1 April 2007 @ 10:55

  11. Yes, I have had that scenario too, where Apache logs to a location that the cheap Web host customers cannot access, or it logs to /dev/null or something… that is when you starting sticking “print “\n”;” after every statement… no fun at all. This is the point that I have really been hammering away at in my blogs for some time now; it does not matter how superior your language is if the tools stink or if the average coder cannot use them. At many levels, I consider Perl to be a better language than VB.Net; I certainly accomplish a lot more per line of code, and write more lines of code per hour. But as soon as I hit the debug/test/fix cycle, I slam into a brick wall, whereas Visual Studio debugs so much better on Web development. As a result, ASP.Net in VB.Net takes less time as an overall process than Perl, even though Perl is the better language that I write better code faster in.


    Comment by Justin James — 1 April 2007 @ 01:15

  12. In general, I haven’t ever had that kind of problem debugging my own Perl. Someone else’s — yeah, somewhat. My own, however, not so much. Every time I’ve had an error, as far as I recall, it has been somewhat obvious where the error occurred. The occasional print-statement debugging was always just a matter of wanting to do a quick divide and conquer — the whole “split it in half, see where it falls” kind of thing.

    I dunno. Maybe I’m just doing different work than you are. Maybe it has something to do with the fact that when I’m working with Perl, OOP is something I avoid unless I really can’t. There are better ways to get code reuse out of Perl most of the time.

    Comment by apotheon — 3 April 2007 @ 11:52

  13. Or maybe it’s just that you’re more in your natural element with Perl than I am. I’m constantly making syntax goofs like forgetting “my” or typing “~=” instead of “=~”.

    Comment by SterlingCamden — 4 April 2007 @ 09:41

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License