3 ms·
The project I mentioned is a legacy codebase that needs lots of work to even get it to consistently raise exceptions. Many places things happen trigger_error is
by craigmcnamara 11y ago
The project I mentioned is a legacy codebase that needs lots of work to even get it to consistently raise exceptions. Many places things happen trigger_error is used, which is not caught by Honeybadger(basically the same as Airbrake) and configuring the code to raise Exceptions for errors leads to bad behavior because previous programmers used trigger_error as a debug mechanism as well. Also there are no tests, so there is no good starting point to correct the transgressions that many PHP programmers don't regard as problematic at all. It's the embodiment of everything wrong with PHP and correcting the abuses is an enormous effort.
I just looked at xdebug, it can't even come close to the Eclipse debugger for Java or Pry for Ruby.
I just get sad every time I see a new large investment in PHP because I've never had a positive experience using it compared to another language and I strongly believe that you can't polish a turd.
- smt88 11y agoI feel your pain. I make a lot of my money maintaining legacy PHP projects, but I'm hoping to entirely get away from PHP in 2016. It's incredibly difficult to fight the "just rewrite it in [some better language]!" reaction whenever I first look at a code base like the one you're describing. > trigger_error as a debug mechanism as well Yeah... unfortunately that sounds very familiar. "Abuses" is a good word for it. At least with Xdebug, you can use breakpoints instead of "var_dump($whatever); exit;" and you can navigate through your stack trace. No, definitely not as good as Java tooling, though.
- manyxcxi 11y agoIf you're just now looking into xdebug, how could you know the differences or make a valid comparison? For one, you can remote debug way easier than with JVM debuggers. For the 80% use case it is just as easy/just as useful. The JVM debugging tools provide way more functionality and for local debugging are just there and ready to use in a way xdebug isn't. But frankly, the fact that you're JUST looking into xdebug makes me question whether or not people should be paying you to write PHP. I have kids fresh out of college that work for me that use xdebug all day every day, remote, over Vagrant VMs, and local with different IDEs. This is a solved issue- you clearly are working in a smelly codebase, don't have the 'advanced' PHP skills you think you do, and seem to think that PHP is awful because the other cool kids said so.
- craigmcnamara 11y agoPHP isn't just bad tooling, it's a bad attitude, like your attitude. I've said that I dislike the PHP experience for many valid reason and you question my competence, experience and validity of my experiences with PHP. I looked in to XDebug and it's not the kind of tool I was looking for. It's heavy weight, requires changing the VM config and from the cached version of the website that is down at the moment appears to imply that it's best used within an IDE. I'd like a REPL debugger that I can activate easily and use from my terminal without fucking with the VM too much. My real goal is to not have to make changes to this project beyond correcting damage inflicted by the PHP attitude of blissful incompetence and copy paste. While I do believe that you can write good code or bad code in any language, PHP does not in any way help it's practitioners to write good code and as PHP users poorly copy my favorite things from my other favorite languages they always miss the mark and loudly complain when the shortcomings are pointed out. I've wasted far too much time responding to you, so you just keep smearing digital shit on the walls, I have code to ship.