I think the difference is that you're using the language as a prototyping/design language: there, shortening the feedback loop is absolutely critical. There are lots of things that are not prototyping though - when I touch a graphical project I typically am working from a diagram that specifies all the color values and has a layout labeled with dimensions.

For a contrast, I don't notice compile times at all in just about any language for the most part: when you reach the "few million lines of code" size, there's no language that is going to be instant; and for embedded/systems work, committing a change can involve things like creating builds for N different architectures and running a test suite that may have to control hardware [run times of the test suite are measured in hours to days]. At this scale, anything that the compiler catches, even if it takes an hour to compile, saves an order of magnitude more time later in the process.

It's legitimately a hard problem to design a language that works well for both projects in the few tens of thousands of lines of code size -- i.e. tossing together a quick prototype -- and scales to millions of lines of code or larger.

> I've always wondered if the difference is the quality of work that we do. For instance, I do a lot of graphical/games stuff, and there's no resolution in my head high enough to know that 200 pixels to the right is too far (or not) without recompiling the app and actually looking at it. Or if that shade of blue is the right one.

I get that there're some differences in the games domain, but I don't quite get your examples, because changing the position or color of objects seems like a data and not a code change. If you have these properties as data you might be even able to change them on the fly, in the running game, which will increase your iteration times quite a bit more than any faster compile times.