Hacker News Reader

Comment by dnzm | Hacker News Reader

apt-get install php5-xdebug and enabling it in the config isn't exactly hard. Getting it to integrate with your IDE might be slightly more involved, but still no rocket science.

It's also something you only have to do once, on your development box. So I don't really consider that a hurdle.

View on HN

It's not so much the degree of difficulty, but rather that the difficulty exists in the first place.

The PHP experience is absolutely horrible compared to those of Java, Python, the .NET languages, and even to those of C, C++ and Objective-C.

Take Java, for example. Debugging works seamlessly in pretty much every major Java IDE, including the free ones, on pretty much every platform used for Java development. This has been the case for a decade now, if not longer. It takes basically no effort to start debugging Java code.

The .NET experience is even better, although more limited in terms of tooling. Debugging is stupidly simple and very efficient when using C# and Visual Studio. Again, it has been like this for many years now.

PHP needs to get its act together so that debugging is at least as simple as it is when using those other languages and runtimes. Anything less is just plain unacceptable today.

+1 if debugging is present out-of-the-box, even first-time users will have no excuse not to use proper debugging.

While installing XDebug may be no rocket-science, I've encountered too many situations that it just didn't work reliably, causing developers to revert to nasty var_dumps() for debugging.

The only things I managed to get working reliably with xdebug were

• break at the first line in a script (very annoying when you have to debug something very deep)

• generate tracing logs (horrible to read but the best debugger replacement I had at the time)

• generate profiling logs (very helpful)

I never managed to get arbitrary breakpoints to work so I basically resorted to either traces or var_dump.

At which point it will happily ignore all of your breakpoints unless you invoke the right voodoo to make everything line up and do this every time you want to use a new system or VM for debugging. Total contrast to every other language where you don't have to think about this stuff.

This is true 90% of the time.

From there, some libraries like ezpublish will cause all sort of problems with xdebug depending on where you put the breakpoint (it might be due to the number of recursive call or stack depth), and you'd really want to enable or disable debugging case by case, from your IDE ideally.

Then debugging on a non dev server means installing a new package, configuring it and disable it afterwards just in case it has ill adverse effects.

Then some eclipse pdt versions were stuck when using xdebug on some configs.

Overall it works, but in practice, there's not enough cases IMO where step by step debugging is valuable enough to bother dealing with the not so exceptional weird things.

> Getting it to integrate with your IDE might be slightly more involved, but still no rocket science.

Which IDE do you use? Granted, most of my issues come from the IDE vendor's browser extension, which only triggers debugging when there's an 'R' in the month... which is highly frustrating.

Reply on news.ycombinator.com