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.