4 ms·

Debug Mode is the Only Mode

60 points by admp 14y ago

mark_h 14y ago
Geo-redirected blogspot URLs are getting a bit out of hand on HN! I submitted this as well (.au): http://news.ycombinator.com/item?id=4799685 http://news.ycombinator.com/item?id=4799685 And of course it was also submitted as .com: http://news.ycombinator.com/item?id=4800296 http://news.ycombinator.com/item?id=4800296 Have an upvote to try and get some discussion on this article, but I wonder how many others aren't making it to the front page because of diluted votes?
- alexpopescu 14y ago
  I don't know when Google started to do this but as you say it's becoming annoying. At least they are using the canonical URI, so maybe browsers should get smarter in interpreting/using this bit of info.
larsberg 14y ago
I agree with his sentiment of "integrate the tools more tightly." In practice, though, that's pretty hard to do in a way that still lets third parties integrate easily into the IDE (I guess it's fine for Apple) because it results in very complicated APIs both in terms of their interfaces and semantics. Semantics (call M1 then M2; if you schedule filter F1 you need to call the old filter chain F1' even if you do nothing, etc.), btw, are where third parties really break IDEs. And then people blame Microsoft/Eclipse. Further, scaling up nifty ideas to all programs and the entire development development process, both in terms of performance and interactions is hard. One guy on my team (I lead a team at MSFT for a bit) implemented "Omniscient Debugging" on steriods (you could also resume from the previous point in time) back in 2002 that we demo'd around, and it took many years to figure out how to build it in in a way that users could understand - happened long after I left. We also had a full working IDE in web browser in 2001; more tightly integrated debug/edit/profile/unit test tools; etc. Fundamentally, though, many of these are user interface problems and it's much easier to come up with a spashy demo than it is to build and ship a real project that works with real code. So, I'd say it's not that the "PL community" has been too focused on static code as separate from dynamic execution of the program, but rather that as IDE designers we don't (or at least didn't ~6 years ago) know how to convey the information to the user without requiring they use an IDE that looks like the cockpit of a 747.
- seanmcdirmid 14y ago
  I disagree. If we make changes to the programming model that allow for better tool integration, we all win. In fact, tooling really is a part of the language, and you should co-design your IDE and language together. Treat any third-party plugin as a language extension. Programming models will always limit the effectiveness of features like edit-and-continue and IntelliTrace, so let's fix that! I don't think the Omniscient log-the-world Debugging is practical, but if we just had some form of deterministic replay, we could take snapshots or even cheaper memoizations at certain points in the program. Going backwards is simply a matter of going back to the last checkpoint and going forwards to the point where you want to stop. I agree that the key is UX, and as Gilad said in the blog comments, they aren't necessarily technological (once we know what the right experience is, we'll build the technology!). Disclaimer: I work for MSFT, though I study this problem in research (MSR/MSRA).
  - nahname 14y ago
    Better debugging is one of those things that helps one group of developers solve problems they couldn't otherwise solve. Unfortunately, it also allows another group of developers to make a bigger mess before failing under their technical debt. I have definitely noticed a correlation between developer debugging skills and clean code practices. Obviously, this doesn't mean one is causing the other, but I would love if there was any research looking into this. It does make me wonder if our time would be better spent finding ways to improve consistency and professionalism in our practices, rather than another new tool to get you out of the mud.
    - seanmcdirmid 14y ago
      You've basically described the primary difference schools of programming thought. Should programming be the act of taking well-defined/understood requirements, a nice clean environment (and dependencies), careful thought, and producing a program that is correct by construction and has little need for debugging? Or is programming a messy affair of poorly defined requirements, crazy environments, and more exploratory, where debugging would then consume more effort than actual coding? I believe more in the latter school, though of course, they are both extremes and I'm a moderate. The mud is unavoidable and we might as well build winches to pull ourselves out rather than spend time trying to carefully avoid it.
tristan_juricek 14y ago
A practical step might be for tool-authors to always ensure their tools are obviously customizable for a variety of initialization needs. Very few IDEs have made it easy to distribute and maintain custom components. Companies that I've seen have custom Eclipse plugins end up having a specialist, which means that the tool itself is too complex for the typical user to maintain. Editors, on the other hand, are typically easier to distribute since you have mostly scripts. But since most places I know of avoid forcing the same editor on everyone, and the scripts are editor-specific, this is usually something a company is afraid of. Few tools I've seen have examples of customization for anything beyond "launch a script". I'd like to see something like "here's how you would manage several background processes during your editor session". Customization needs to be brought into the realm of things typical users should do, not something they merely can, if they think about it.

60 points by admp 14y ago

Geo-redirected blogspot URLs are getting a bit out of hand on HN! I submitted this as well (.au): http://news.ycombinator.com/item?id=4799685 http://news.ycombinator.com/item?id=4799685 And of course it was also submitted as .com: http://news.ycombinator.com/item?id=4800296 http://news.ycombinator.com/item?id=4800296 Have an upvote to try and get some discussion on this article, but I wonder how many others aren't making it to the front page because of diluted votes?

alexpopescu 14y ago
I don't know when Google started to do this but as you say it's becoming annoying. At least they are using the canonical URI, so maybe browsers should get smarter in interpreting/using this bit of info.

larsberg 14y ago

I agree with his sentiment of "integrate the tools more tightly." In practice, though, that's pretty hard to do in a way that still lets third parties integrate easily into the IDE (I guess it's fine for Apple) because it results in very complicated APIs both in terms of their interfaces and semantics. Semantics (call M1 then M2; if you schedule filter F1 you need to call the old filter chain F1' even if you do nothing, etc.), btw, are where third parties really break IDEs. And then people blame Microsoft/Eclipse. Further, scaling up nifty ideas to all programs and the entire development development process, both in terms of performance and interactions is hard. One guy on my team (I lead a team at MSFT for a bit) implemented "Omniscient Debugging" on steriods (you could also resume from the previous point in time) back in 2002 that we demo'd around, and it took many years to figure out how to build it in in a way that users could understand - happened long after I left. We also had a full working IDE in web browser in 2001; more tightly integrated debug/edit/profile/unit test tools; etc. Fundamentally, though, many of these are user interface problems and it's much easier to come up with a spashy demo than it is to build and ship a real project that works with real code. So, I'd say it's not that the "PL community" has been too focused on static code as separate from dynamic execution of the program, but rather that as IDE designers we don't (or at least didn't ~6 years ago) know how to convey the information to the user without requiring they use an IDE that looks like the cockpit of a 747.

seanmcdirmid 14y ago
I disagree. If we make changes to the programming model that allow for better tool integration, we all win. In fact, tooling really is a part of the language, and you should co-design your IDE and language together. Treat any third-party plugin as a language extension. Programming models will always limit the effectiveness of features like edit-and-continue and IntelliTrace, so let's fix that! I don't think the Omniscient log-the-world Debugging is practical, but if we just had some form of deterministic replay, we could take snapshots or even cheaper memoizations at certain points in the program. Going backwards is simply a matter of going back to the last checkpoint and going forwards to the point where you want to stop. I agree that the key is UX, and as Gilad said in the blog comments, they aren't necessarily technological (once we know what the right experience is, we'll build the technology!). Disclaimer: I work for MSFT, though I study this problem in research (MSR/MSRA).
- nahname 14y ago
  Better debugging is one of those things that helps one group of developers solve problems they couldn't otherwise solve. Unfortunately, it also allows another group of developers to make a bigger mess before failing under their technical debt. I have definitely noticed a correlation between developer debugging skills and clean code practices. Obviously, this doesn't mean one is causing the other, but I would love if there was any research looking into this. It does make me wonder if our time would be better spent finding ways to improve consistency and professionalism in our practices, rather than another new tool to get you out of the mud.
  - seanmcdirmid 14y ago
    You've basically described the primary difference schools of programming thought. Should programming be the act of taking well-defined/understood requirements, a nice clean environment (and dependencies), careful thought, and producing a program that is correct by construction and has little need for debugging? Or is programming a messy affair of poorly defined requirements, crazy environments, and more exploratory, where debugging would then consume more effort than actual coding? I believe more in the latter school, though of course, they are both extremes and I'm a moderate. The mud is unavoidable and we might as well build winches to pull ourselves out rather than spend time trying to carefully avoid it.

tristan_juricek 14y ago

A practical step might be for tool-authors to always ensure their tools are obviously customizable for a variety of initialization needs. Very few IDEs have made it easy to distribute and maintain custom components. Companies that I've seen have custom Eclipse plugins end up having a specialist, which means that the tool itself is too complex for the typical user to maintain. Editors, on the other hand, are typically easier to distribute since you have mostly scripts. But since most places I know of avoid forcing the same editor on everyone, and the scripts are editor-specific, this is usually something a company is afraid of. Few tools I've seen have examples of customization for anything beyond "launch a script". I'd like to see something like "here's how you would manage several background processes during your editor session". Customization needs to be brought into the realm of things typical users should do, not something they merely can, if they think about it.