…those who think Edit and Continue is a good idea and those who don’t. I still haven’t gotten to answering Franz‘s original question, but a recent entry he made does start to address the question.
I totally understand what he’s saying when he talks about the fact that Edit and Continue allows for some very bad programming habits. I spent a few summers teaching teenagers to program, and I got to see first hand some of the ways that bad habits can derail programmers, especially new programmers. From a theoretical standpoint, it is infinitely preferable for programmers to follow the well-worn steps to programming nirvana: understand the problem, design the program structure, implement the program, test the program, fix the bugs, ship the program. In that order.
And yet… The reality is that life is messy and does not always conform to theoretical norms. I am a skilled programmer who works on a major product produced by a large corporation. But even I have lots of times where the code that I write only needs to be “good enough” and not brilliant. I’m not talking about the VB compiler here – obviously, that has to be brilliant – but about all the side projects and throwaway tools and prototypes and test cases that I work on in my day to day life. It doesn’t matter that they’re well designed, only that they work.
And that’s what makes Edit and Continue so wonderful. When I need to bang something out rapidly, I can design the application on the fly. I outline the application, hit F5 and I’m off, writing the code as I go along. If I made a mistake, no problem, I can fix that on the fly without having to restart the entire application. If I’m working on something that really needs to be polished up later, that’s cool – I can do that later. But for now, I’m getting my work done and I’m doing it without all the theoretical design overhead that I really don’t need at that moment. And there are a lot of people in this world who just need to get their work done like this and don’t need to produce well-designed, meticulously thought-out applications. That’s why Edit and Continue is such a big feature for them.
(I’ll also add that I suspect that many, but certainly not all, developers who do not want Edit and Continue haven’t really tried it. Even for people who think fully through their design and eschew debugging on the fly, there is always those times when you hit an exception 10 minutes into running your application and you realize that you just forgot to initialize some stupid variable. If only you could just fix that one damn line and not have to re-run the application again for 10 minutes… If only…)
Anyway, like I said, I’ll freely admit that EnC can enable people to slide by with some pretty bad habits. But if people find it useful, why not do the feature and allow people to decide for themselves whether they’re going to have bad habits? The purpose of a tool is not to make people use it in the “correct” way, the purpose of a tool is to assist people in getting something done. That means that just because someone might misuse a feature does not, in and of itself, mean that you shouldn’t do it. This is really a core philosophy of VB: whatever it takes to give you the shortest path between your idea and a completed application. That’s RAD.