Debug Mode is the Only Mode | Hacker News Reader

Debug Mode is the Only Mode

gbracha.blogspot.co.uk

60 pointsadmp12 comments

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.

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).

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.

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.

I haven't really seen such a clean divide. There is definitely a group of developers that prefer building over everything else. This group loves tooling because it enhances their ability to keep adding new things. I also suspect that this group is a product of their environment. They are exceptional at debugging because debugging is the primary way of working. A problem is to be understood and additions made, not changed. Change ruins their understanding.

But even this definition feels too confined. There have been some developers I worked with that must have started out this way and then learned 'engineering' practices. They were all exceptional to work with. I wish more of this group could get to that level. Hence my interest in putting bread crumbs on the path to learning, rather than yet another pill to lose weight fast.

There is definitely a big difference between an inexperienced developer and one who is experienced and follows rigid organization practices. But even these latter people probably debug a lot, you just don't see it from the outside.

Debugging is as close to experimental science as we get in computer science. It is the act of understanding a complex system, and even if we built that system entirely by ourselves (unlikely), it eventually "gets away from us" and takes on a life of its own. It is impossible to understand everything, and debugging is a great way of allowing us to forget details and uncover them later.

IMO it is not the programming model that needs to be changed, but the tool chain creating around the programming model that needs to be built with a larger horizon of ideas & ideals in mind.

So far most of the tools have been created in a very strict, single purpose way. While that's a good engineering approach it also leads to limitations that are hard to overcome. I do remember the early days of Eclipse when they had to build their own java compiler to be able to pull out enough data for the IDE. And that's the simplest example. Or think of the days before JMX.

Obviously this is not a simple problem to solve. I think the only way we could fundamentally change things is to completely rethink the way programming models/environment are thought.

Have you all looked into pluggable types at all? It'd be nice to be able to enforce a convention like, any class annotated with type x must prefix all methods which call into y with z, and be given warnings/errors at build time. Forgive my ignorance if this is already doable, I work in OS X.

> 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.

You can have IDE's that don't have quite this problem in environments like Smalltalk. Since you can see all of the source code, and easily tweak and debug the whole system, every part of the system is your API. Unfortunately, this can also result in hard to manage dependencies when people publish extensions.

The way to have the best of both worlds, is to have an environment as described above, then also have a community process that promotes innovative extensions and rewrites them into more conventional APIs. This way, such APIs respond to actual need and no genius system designer has to foresee all the ways people will want to extend a system in the future.

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

And of course it was also submitted as .com: 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?

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.

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.

Reply on news.ycombinator.com