4 ms·

> we can no longer use f5-debug Sums up what is still one of the major issue-slash-weirdness of the php dev world. For all the frameworks and language advance,

• deleted 8y ago
  [deleted]
• ben_jones 8y ago
  I still print debug quite often in Go, I don't thinks its always less efficient then a debugger, and even when it is I don't think its always 10x less efficient. I think it depends heavily on the type of software you're working on. For webapps in particular there can be a lot of value in constantly reloading the page. For example it can allow you to more often visually inspect the page for ui/ux/performance improvements. Particularly in early stages of a user interface where you're still figuring things out.
• sagichmal 8y ago
  > Can you imagine debugging your C/C++/Rust/Go/... programs by adding printf everywhere and re-run the whole thing ? Yes, absolutely. This is my principal and nearly-exclusive method of debugging the distributed systems I work on all day.
  • zem 8y ago
    same. i find a debugger useful for tracking down segfaults, but for debugging logic it's printf all the way.
  • groestl 8y ago
    It's true that for distributed systems, logging tends to work better/is a necessary first step. I'd still want to invest in an extensive test harness though, if you can afford that luxury. Usually this enables productive debugging for distributed systems code, which pays of quickly.
    • sagichmal 8y ago
      Agreed, a deterministic test harness is critical, especially when working on the inner components, like state machines.
    • stcredzero 8y ago
      There was one network monitoring company that used Smalltalk, and Smalltalk's ability to very rapidly save the entire memory image. Basically, for exceptions, a snapshot of the server's state could be saved off in addition to the log, then brought up later, completely live, with a debugger on that very method. (Definitely a distributed system, running on other people's hardware in other people's data centers.) I worked at another company where we used a different kind of Smalltalk serialization to save the GUI's state in an auto-generated error email or log entry, so we could open the application in the exact same UI state when dealing with a bug.
  • smt88 8y ago
    Most people aren't working on distributed systems though, so debuggers work fine for them
    • merb 8y ago
      well it's hard to find a race condition with a debugger. sometimes it would just work with the debugger since you slow down the program or maybe halt on the wrong places.
      • teh_klev 8y ago
        Sure, but I'd argue that most developers aren't working with code day in and day out where race conditions are a concern.
        • merb 8y ago
          well it depends, I mostly try to create my code so that things can run in parallel. I also barley use a debugger, even for code that does not run in parallel, mostly because I'm used to make logging calls at the right places so that I can find issues way faster than with a debugger (most often I'm only run into hard issues or issues where a debugger will fail, i.e. build scripts -_-)
      • singlow 8y ago
        The point is that the debugger is an essential tool for debugging because in most cases it will do what you want and is faster. Most coding errors are not race conditions. I don't know why everyone must pipe in with the edge cases where a debugger might not work. In 99% of scenarios where you want to test some code in a development environment, setting breakpoint is the quickest way to see what is wrong. Log output is useful too, and you will probably use both. But, if you are a developer and don't have the ability to step through your code in a debugger, many problems will take much longer to fix.
  • haggy 8y ago
    It depends what the issue is. I work on dys. systems almost exclusively and if you can reproduce locally, I can almost always run the project using multiple procs with a debugger attached to each one of them
  • kbenson 8y ago
    It's often much faster to just print or dump some data to screen just to see where your assumptions have gone wrong. There's a point at which some bugs become more complex, or just aren't easily figured out from this method, but it's surprisingly quick and powerful when used in conjunction with a language in which doing so is quick and easy. Doing it in a project that requires a few minutes or more just to build can quickly change this equation, but this is my go-to initial method for debugging problems. Then again, it's generally pretty easy for me since I develop with liberal use of debug messages and dumping of data structures at multiple locations depending on the value of the DEBUG environment variable. In production I just run without a DEBUG environment prefix and nobody is bothered by the verboseness, but if there's a problem, step one is generally just doing a test run with DEBUG=3 or something prefixing the command. It's a bit different for web-based scripts like in PHP, but not much so (just make it a param), as long as STDERR goes to a log file.
• stabbles 8y ago
  The php dev landscape is pretty wide. On the one hand there's wordpress developers that can only use "f5-debug", on the other hand there's software developers that use TDD with PHPUnit and Behat.
  • jwdunne 8y ago
    The thing I find most hard about WP development is that there isn't much else you can do. It's like one bootstrap file bootstrapping another, with hooks peppered throughout. The majority of your problems will lie in the integration of a handful of plugins. Otherwise, you're better off doing something else. It plays like a out of tune orchestra. Sure I could hook up xdebug. In fact I have in the past. I profiled the beast. The call graph made mu forehead feel like a lead weight. But if I'm working on a project with components of my choosing, I'm free to make liberal use of PHPUnit, both for unit testing and heavier tests that involve the whole stack. Debugging isn't as smooth as debugging JS or typescript so I lean more on logs and object dumps. Might be different if I used PHPStorm but that feels sluggish to use - says something when I use Emacs with tonnes of packages. It is possible to do higher quality programming in PHP but WP isn't a friendly environment for that. And environment goes a long way.
• sethrin 8y ago
  Is there empirical evidence to support the idea that PHP developers do not use xdebug? If not, perhaps you can explain why you think this? I have largely stopped coding in PHP, but I did use xdebug when necessary. I have very little idea of other developers' workflows, but I am very skeptical of this claim.
  • smt88 8y ago
    I consulted with ~12 teams of PHP (not WordPress) developers between 2004 and 2016. Some were in the US, some in Europe. Zero of them used xdebug until I forced them to.
    • sethrin 8y ago
      Interesting. Which framework(s) were these teams using? How large were they? xdebug is not always the most straightforward thing to set up. I don't tend to bother with it unless I am doing a lot of PHP development (which fortunately has not been the case recently). I've also had less cause to use it since the introduction of the Psy shell. It's still something that I would consider an essential tool, and I do wonder at the circumstances which allowed these teams to be able to get by without it, but the experience could maybe be a bit smoother. I did not think that the ST2/ST3 or Atom integration was that great; the best experience I had was with NetBeans, but NetBeans is otherwise pretty clunky. Presumably your mileage varies somewhat.
      • smt88 8y ago
        Frameworks varied, but included Laravel, Symfony, and Cake. Some code bases were spaghetti. I agree that xdebug is hard to set up. I only had reproducible success with it after Vagrant became mainstream. Otherwise we had to share a dev server with all the team members in their own directories, and getting xdebug running on the dev server was a trial-and-error headache. Debugging is one of the reasons I can’t recommend PHP to anyone for any purpose anymore.
    • conradfr 8y ago
      I've been a PHP developer for a long time at many companies and I've always been the only one using xDebug. People generally find setting it up confusing (which it can be). Also xDebug can't discriminate if you have multiple projects running in one fpm etc which can be irritating if your request hit many of them (ie calls that can't be mapped in your debugging session).
• donatj 8y ago
  > Can you imagine debugging your C/C++/Rust/Go/... programs by adding printf everywhere and re-run the whole thing ? I'd say 90%-95% of the time that's entirely sufficient. "The most effective debugging tool is still careful thought, coupled with judiciously placed print statements." - Brian Wilson Kernighan
  • bpicolo 8y ago
    That's really missing the best part of drop-in debugging, which is taking advantage of the REPL. You see what's wrong, and then can fiddle with code to see the exact lines of code to put in place to resolve the issue. REPL-driven development is pushed hard in e.g. Clojure land, but it's an insanely productive workflow in a ton of different languages
• eikenberry 8y ago
  The only time I've found debuggers useful (vs. logs/prints) is when I inherit a pile of spaghetti code and want to see poke around at things. Other than that debuggers are much slower than running the code with a flag that enables the debug logging. IMO the ability to easily diagnose and debug issues is a feature of the code/application and should be taken into account when writing it. Having to fall back on a debugger means your dealing with something not written with maintenance in mind.
  • smt88 8y ago
    I'm not sure what you're missing about using debuggers, but it's something. Breakpoints and stepping are massive time savers. You can easily replace dozens of runs of a buggy program with a single debugging session. It's genuinely shocking that anyone would argue that debug mode is better.
    • z92 8y ago
      You also need dozens of stepping and breakpoints with a debugger. A dozen of runs with printf doesn't take more time than a dozen of stepping within a debugger. Reminds me of the classic old debate of command line vs GUI app. GUI might be easier to run, but command line apps are easier to automated, and overall better suited for power users.
      • smt88 8y ago
        Setting a breakpoint takes less time (and shows drastically more of the current state) than printf. Some breakpoints are automated, like breaking on exceptions. There's also the problem that printf affects output for web programs and therefore isn't feasible if you want to eventually see what the output is. It's like you have a sick patient and want to see how they're doing by cutting them in half. X-rays and scans make far more sense.
• cronix 8y ago
  I think there is kind of a big difference though in that you don't have to compile php to execute scripts vs the languages you named. It's often just a lot faster to add a single loc to dump output to the page and immediately rerun the script and get immediate output. Debuggers are great, but not needed for the more simple bugs, which tend to be most common. If php devs had to wait a few minutes (or longer) to compile first, just dumping the output wouldn't be an efficient option. Not all bugs need tracing and stepping, but when they do it's great to be able to use the actual debugger.
• Zelphyr 8y ago
  I've found that it's only when I use a framework that I absolutely need X-Debug. Otherwise it's a nice-to-have but not a requirement.
• z3t4 8y ago
  php script life time is usually about 1 ms. dont you think attatching a debugger to that is a bit overkill !?
• jstewartmobile 8y ago
  C/C++/Rust/Go: Compiled language Stockholm syndrome. Time difference between printf() & F5 vs. setting up breakpoints and watch variables in a debugger is going to be negligible in something like Ruby/Python/PHP. Also, everything is so damn framework-heavy these days that stepping until you strike gold can take a very long time. Super-verbose logging would probably be more effective.
• toast0 8y ago
  Printf debugging works everywhere though. Debuggers are cool, but mostly what happens when I attach a debugger is I get to see all the things that timeout when I step through the code. Not to mention all the fun of trying to get remote debugging to work consistently... var_dump into a log file gives me what I need most of the time in seconds.
• AlexCoventry 8y ago
  You want both methods, of course, but if I were forced to pick just one it would be printf-based.