I've seen others do similar things (including beginners I was trying to teach), although in languages like C/C++, and I do not think it is a good idea at all. It leads to "tunnel vision" and concentrating on small pieces at a time while ignoring the "big picture" as well as mindless fiddling with code in an attempt to "get it to work", which pretty much leads to worse code quality overall and a decrease in productivity. I suppose it may feel productive to be making lots of small changes and seeing the results immediately, and somewhat addictive too, but my experience says that it's not. I recall helping a coworker who had spent several hours messing around with a small fragment of code that he was sure was causing a bug; he had made lots of little changes and yet the problem remained, but was reluctant to look somewhere else because he was almost addicted to that allure of "just one more little change... hope this fixes it...!" I told him to stop doing that and think more about the data coming into that piece of code and going out, which it turns out in its original unmodified form was perfectly fine --- the problem was actually somewhere else, and later was fixed in a few minutes after he made that realisation. If I hadn't intervened I would not be surprised if he spent another few days of fruitless labour.
The other thing that this sort of interactivity/short-edit-continue-cycling is heavily promoted for is learning, which IMHO is probably the worst way to do it; it's essentially encouraging programmers to write code without actually understanding what they're writing, and when it doesn't work, to try random things until it does. That's no way to write good software.
It's better to spend more time thinking about the problem, writing, and then proofreading code before even trying to compile and run it, than try to write something you vaguely think may work and then spend much more time debugging and "fixing" it. Those from the latter school of thought are often surprised when they see me write several hundred lines of code and it works perfectly the first time. To me, it's the other way around... seeing those who can't write more than a few words without making blatant syntax or logic errors.
In other words, "reducing the cost of mistakes" may only encourage making them; and in any case, does not discourage it.
While it's true that shorter write/run cycles can encourage a throw-spaghetti-at-a-wall approach to programming, the other side is the Bret Victor point of view [1], i.e. that a programming environment that clearly exposes the behavior of the computer and allows the programmer to react to it can help her more easily form a mental model of the program's behavior. People can only keep but so much program state inside their heads, so careful thinking will only take you but so far. I'm optimistic that in the long-term, developing these kinds of interactive programming tools will be a net positive for programmer productivity even in the face of additional bugs that may be introduced.
It’s useful to realize Edit and Continue is not for professional programmers, and the qualities we’d most want are not appropriate to every problem.
The horrible code you inherited as the programmer brought on is because some non-professional domain expert made a ‘hairball of extreme utility’ that unlocked product-market fit on back of a mess of experiments.
VB’s persona was ‘Mort’, literally a scientist trying to get an answer, or a business person trying to solve a problem, not a programmer trying to build a system. It’s 99 hairballs of no utility and 1 that wouldn’t have been built otherwise because no one knew it was useful until it exists.
Some categories of UI experience problems lend themselves to simply making the trial loop as quick as possible.
It is also true that understanding a dataset has an initial experimental component. No amount of thinking about code is going to tell you the dataset has a fatal flaw, until you discover it.
In the old adage "there are two difficult problems in programming: caching, naming things, and off by one errors" edit and continue drastically helps with the last one (even for "professional programmers"). I loved that feature in C# while I was working at MS, it saved me so much time from checking that all my indexing was correct.
I agree with you and poorly worded this for a larger audience that doesn’t have the full context of design decisions on the feature.
As an example ... for a ‘professional programmer’ there is an argument that allowing E&C to work if you edit in vim or emails is a feature. For what we needed to accomplish that is an anti-feature.
> Edit and Continue is not for professional programmers
Then I prefer to be called an amateur, as I really like using that feature, instead of loosing my debugging context and starting everything from scratch, some times spending several minutes trying to replicate the issue that landed me there.
Not sure if I'm reading incorrectly into the tone of your response, but, for context, 'SteveJS was a developer on that feature, as he says elsewhere in the comment tree.
I think it is more than fine to use Edit and Continue as a professional. I’m acknowledging the trade offs and making an argument meant to be heard by a resistant audience that is likely to be the ones making the tool.
E&C is a useful tool, just like a debugger in general is a useful tool, despite early enthusiasm for unit testing having people claim you shouldn’t use debuggers anymore, but instead write unit tests to debug every issue. E&C can be misused. If i was using C# i would take generics over edit and continue if I could only have one, but I definitely prefer to have both.
The theory behind using personas is you get a better tool or solution by highly focusing on a concrete user rather than spread around a bunch of features across every possible customer. What i expressed is what is necessary to ‘get through’ to someone who hasn’t read a book like ‘the inmates are running the asylum’. That was true of many in Devdiv back at that time. UX is now recognized more firmly as a separable highly valued skill. If you read and understand the persona and still think ‘i’m a programmer, this is a dev tool, my opinion is more import than what the persona would want .. that is the audience for the above. I think that is what is present in the comment to which i was replying, so i was attempting to put it in those terms.
I do believe it is helpful to understand who a tool is designed for to see why it works as it does. Edit and continue when done well is incredibly ‘safe’. It does what you expect every single time, even if you don’t know how it is doing it.
A good example where there is a hard choice is changing a linq statement. To make E&C in a dev tool that holds true to ‘what is on the page is what runs’ you need to violate aspects of how deferred execution works. If the closure was already captured are all existing instances of them going back to the source as it is on the page now or the source as it was when when captured? I have a strong opinion that it should be the source on the page now to build a good E&C, but that choice is detrimental to learning what is happening with any type of deferred execution. The cost of implementation for my opinion is also probably two or more orders of magnitude in effort.
I also think ‘non-professionals’ should be able to program and get to something that works. Particularly in people who write developer tools the bigger chore is gaining empathy for people who deserve to program, but simply aren’t making infrastructure. My reply is counterproductive in trying to model proper empathy so thank you for calling that out.
I think there is a lot of merit to what you say here. For example, one of the strongest realizations I had while using an interactive programming tool was while hacking on a 30-50 line function I wrote. In the process I thought to myself "gee, I'm glad I have this tool otherwise I would have no idea what is going on!".
However, before long, I realized I needed the tool because the function was too long and needed to be split into smaller pieces. In that case having the crutch of an interactive programming tool led to worse code. Once I refactored the function I realized there wasn't much need for the tool anymore.
That being said, I have taught many a student to code and can't tell you how many conversations have ended with me saying "Maybe it will work. I'm not sure. Just try it!". Students (not all) in an unfamiliar environment will sometimes overthink things rather than trying a failing quickly and correcting their mistake. In this case, failing quickly is an indispensable tool to help student "hone in" on the solution and make progress towards it.
Of course I have seen a fair number of students engage in "shotgun programming", switching a < operator to a > operator and hoping that it will work, so obviously there needs to be a balance.
I really, really, really don't understand what it is that you're saying here. Slow compile times make better programmers? And you base that on one anecdote? And somehow your example coworker would transform into a sensible programmer if you add a Sleep(30000) in the compiler? According to you, it is better if the compiler always makes everyone wait for long periods of time than letting the programmer decide when to pause and think? What??? Are you serious?
When I build C++ stuff at home I go to great lengths to shave milliseconds off my compile time, because it is just so much better to have your program built in under 2 s than in 2 minutes.
The other thing that this sort of interactivity/short-edit-continue-cycling is heavily promoted for is learning, which IMHO is probably the worst way to do it; it's essentially encouraging programmers to write code without actually understanding what they're writing, and when it doesn't work, to try random things until it does. That's no way to write good software.
It's better to spend more time thinking about the problem, writing, and then proofreading code before even trying to compile and run it, than try to write something you vaguely think may work and then spend much more time debugging and "fixing" it. Those from the latter school of thought are often surprised when they see me write several hundred lines of code and it works perfectly the first time. To me, it's the other way around... seeing those who can't write more than a few words without making blatant syntax or logic errors.
In other words, "reducing the cost of mistakes" may only encourage making them; and in any case, does not discourage it.