Programming is an inherently interactive task. It involves a continuous cycle of action, feedback and more action. Once the first draft of a program is written, it is compiled and run and any errors and bugs have to tracked. The source code is then changed and the whole process starts again. However this process of interaction is not quite as seamless as it might be made out to be. Anyone who has ever sat around waiting for code to compile will know that large swathes of time can be spent just sitting around. And the larger your project is, the more time you will spend just waiting. A lot is made out of how much software companies lose to employees playing games, chatting and reading blogs. The loss to long compile time may well be more, or at least it was.
With the rise of purely interpreted languages, the long waits required for compilation have shortened considerably. Modern compiled languages like Java and C# also have fast compilation tasks since they compile to an intermediate bytecode rather than straight down to binary. In both these cases there is still a fast compile time (or no compile time at all) is gained at the cost of a slower execution time. Is this a good thing? This raises the question of programmer time vs. machine time all over again. These modern languages allow for much better use of a programmers time at the cost using more machine time. In most cases, this tradeoff is not only acceptable, it would be foolhardy to go the other way. There are multiple reasons why Java has won away many programmers from C and C++ and this is one of them. The increase in interaction gained from using something like Java and C# means that programmers can spend more time actually working on their code, seeing it respond to use, catching bugs and fixing them. Debugging is one of the most tedious and hated aspects of programming. Programming should be fun, but debugging can turn it into a horrid game of finding the needle in the haystack. The feeling of hopelessness that you get when all you can do is watch your compile messages stream by can make the experience all the more painful. Once again, increased interaction puts the fun back in programming. Imagine playing a first person shooter where you could only take one shot a minute and then compare that to what a modern FPS is really like.
So much for the professional programmer and the software company. What about the fresh young computer science student like me? There are two aspects to reducing compile times and increasing interactivity. Firstly, it does make things more fun. It’s faster to poke around in your code and see what happens. You can try out more than one approach to a problem without feeling like you’re wasting time. I feel that encourages you to look beyond the most obvious solution to find ones that are more efficient but require more effort. Of course it helps if the instructor rewards innovativeness and elegance and not just simple correctness. As one of my senior friends likes to remind me Computer Science is an experimental science. It helps when your experiments take less time for the simple reason that you can then do more of them to find out what works best.
However the flipside of making experimentation easy is that it can encourage sloppiness and discourage careful thought and planning before starting to code. I’ve experienced this first hand while doing a semester project. I was coding in Java and I believe the speed of recompiling encouraged me to just make random changes hoping they would work. Would I have done the same if I was coding in C or C++? Probably yes, because the core problem was deeper than a question of programming language, but I am certain the randomness of my changes would have gone down. Less importantly, but more obviously, I’ve become considerably sloppy when it comes to syntax. I still make silly omissions even though I have been coding in Java extensively for over 5 months now. I would probably be more careful and would reread my code if I knew that I would be incurring a significant time penalty for every compile-time error. Unfortunately there are no easy to mitigate these adverse effects. The only solution is discipline and commitment on the part of the student. Bad habits are hard to break, so it would be better to simply form good habits in the first place.
Just as there have been advances to programming languages to encourage more interactive programming, their have been improvements to the programming environments to support interaction. My first introduction to interactive programming was probably using good old Logo turtle graphics, which is decades old, but the concept has been recreated numerous times. The step to C++ meant a jump down in interaction, but I’ve recovered much of it with Python. Python and Ruby have interactive interpreters which let you enter statements and see their results immediately. It’s a very good way to test out a small chunk of code before actually implementing it, because you don’t have to write the wrapper functions or classes before seeing what may happen. It’s hard to improve on the concept of an interactive shell. Once you can execute program statements directly, if you have the proper libraries, you can interactively create things ranging from simple number crunchers to GUIs. Of course, there’s a time when you have to stop being purely interactive and commit code to program files, but even then, you can test the code you’ve saved interactively as well. I often wish that Java had something of the sort, especially when my programming assignment involves writing only a method or two without worrying about the rest of the class. The BlueJ IDE allows this to some extent by allowing interactive object creation and testing, but I’m not sure if the other larger IDEs have similar features.
So where is interactive programming going in the future? It seems that interpreted languages with almost no compile time are gaining popularity and the use of interactive IDEs should increase as a result. There are also programming education projects that I find very interesting, especially MIT’s Scratch. Things like this make programming more appealing to younger children, something that is essential if the computer science field is to continue to thrive on an abundance of powerful, imaginative minds, like it has since its inception. As our machines become more powerful (both through increase in speed and by parallelism) compile times will continue to fall meaning that even programming in close-to-the-metal languages will become less tedious and more interactive. We’ve come a long way from the days of batch processing punch-card programs and waiting hours for the results. I don’t think we’re going to stop anytime soon.