Every programmer knows that the hardest kind of bug to find is the semantic bug.

Every piece of code will be guaranteed to work for the first line written.  Maybe, even the first five (5) lines will also work, but what if you have a web of functions and a nasty thousand liner code to write?  This is where debugging is going to be challenging.

Before the web, standalone softwares or the "install-me" programs are what are rampant.  It has called programmers into perfection in coding, skill, and testing.  Some have perfected standalone/software programming in different languages.  You've known C/C++, Pascal/Delphi, Python, Java, VB, etc.  Programmers took their own path and strengthened their skills.  There came about many integrated development environments (IDEs) that can help you speed up process of development.. including debugging.

Soon, web scripting took the limelight.  More and more people have put efforts into putting things on the web.  Before social networks came about, only companies and well to-dos can have their own websites and thingies on the net.  But since the birth of the easiest and most common scripting language–PHP, things took on a different turn.  Now, it seems the group of software developers have split into two.  Some are now doing softwares and some are now into the web.

The popular web scripting that came about are PHP, Javascript, JSP, ASP, VBscript, CGI/Perl, Python,  and now, Ruby.  But since these web scripting, how has the debugging process changed?

Softwares are compiled.  Web pages are browsed.  There have also emerged a lot of tools and frameworks to assist/aid in proper development.  Some have  already eliminated bugs in the process of its existence, yet some bugs are just too difficult to find since they blend well into the perfectly syntax-bug free code.   The old fashioned, yet reliable breakpoints are no longer easily implemented in web scripts.

Taking PHP for one, there has not been a lot of debugging tools around.  Except for some that are built in IDEs, there are no other way of debugging than to insert snippets of code for tracing.  Javascript may be easy to debug using the Console of Firefox or the scripting window of IE, but the other scripting languages pose more challenge in the debugging aspect.  It has remained a crude method.

Looking up things over the net, out of curiosity, I've found the following things:

  • There is the jsTracer for tracking using Javascript.  I think it has a potential.  But its useful mainly for Javascript debugging.
  • A simple debug script that includes your PHP file and executes it inside the script.  This is great for small quick PHP pages, but not for huge files that are a lot complicated.
  • PHPEclipse for setting breakpoints.  This is just great since it simulates the necessity of tracing over certain bottlenecks just like how its done in software development, but at worst, you'll have to do extra coding for you to be able to use breakpoints.
  • A short but sweet file that works like the "debug script", but this time, it allows you to type in your php code inside a textarea and execute it.  So, the debugging appears to be a little more interactive.  Its called the PHP commander.
  • Firefox's Great Add ons prove to be something worth exploring.  Someof these are: Web Developer, Firebug, Modify Headers,
  • This one.. proves to be a solution I'm more willing to try.. Its called the JavaScript Powered PHP Debugging.  This provides Javascript functions that can be invoked by your script either through include files or classes that will create a remote Javascript controlled window where you can print messages or dump variables as need and as the script is executed.

I think.. I'll have to try that last item.  I miss breakpoints.. C's breakpoints to be exact.  JavaScript Powered PHP Debugging may help a bit, though it won't really be anywhere close to having breakpoints in web scripting.