Front page | perl.perl5.porters |
Postings from November 2011
* Craig A. Berry <craig.a.berry@gmail.com> [2011-11-27 01:00]: > Vadim got a bit carried away, but he had serious concerns that I don't > really think have been addressed. Basically, changes to the debugger, > even innocent-looking ones, are likely to break something. When Dave > Mitchell was passing over all debugger changes in the final days > leading up to 5.10.1, he said, "anything to do with the debugger is by > definition scary."[1] Anything that scares Dave ought to absolutely > terrify most everyone else. > > I'm not seeing a sufficient level of terror here. A debugger almost by > definition is a bit of black magic that sits in a very intimate > relationship to the implementation of the language being debugged and > needs to be shark-like in its primitivity in order to avoid higher > order constructs that may not be working right (and are thus in need > of debugging). > > The argument that strictures and warnings are a good thing to have in > Perl programs generally and since perl5db.pl is a Perl program > therefore it should have strictures and warnings is essentially > a "witches are made of wood" argument. Despite the .pl extension, the > debugger is not any ordinary Perl program. For one thing, it needs to > function in extreme environments where ordinary Perl programs cannot. If I follow this to its logical conclusion then it tells me perl5db.pl has to be reduced to a very minimal core debugging engine and the console UI that same the file also implements must be split out – since the former needs great care in modifications, while the latter is rather normal code that should be ordinarily maintainable. Separating them out would allow to increase the pace of changes to the UI without increasing it to the engine. (Obviously, splitting them apart would be a big change as the first act to set the stage for this ostensible reduction…) This is also a better defence against the “what if the perl core changes and breaks perl5db.pl and no one knows how to fix it” scenario, because what needs fixing is then only the engine – a smaller piece of code. > Here's a real-world example that has cost me an hour or two today. […] > miniperl Anything that needs to work under miniperl has to have various special considerations addressed. I see no indication here that this problem was caused by the nature of the debugger, rather by the nature of miniperl. Therefore I believe that if insuring against such breakage is important, the right way would be to add tests that check (at least minimally) that functionality which should work under miniperl actually does. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>Thread Previous | Thread Next