All my Java programming has been done in Eclipse which does a wonderful job of flagging errors as you type. That is, the development cycle of “write, compile, fix compile errors, compile, …, run” because if Eclipse doesn’t show any errors while you’re typing, it’s sure to compile.
One of features of Java is it’s ‘strong typing’. I don’t care about the JVM runtime checking (since code has to be robust and recover from all errors, the overhead of checking rather than just doing and faulting is questionable) but I care about the compiler and, in this case, the editor knowing what I want to happen — if I say
itemCount is a string but then I add one to it something should be flagged; if I define a variable named
height and then reference a variable named
heigth something should ask me what I was thinking. This feature of the programmer defining something and then the compiler or editor being able to check the implications of that definition.
I have the same arguement with PERL and most of the XML languages (a typo in an XPath expression silently select nothing with know why to debug why, for instance). CSS is hard to get right on web pages because there is no check if the HTML being styled fits the formatting model that the CSS operates on. C++ lets you override methods in subclasses with no checking for the matching semantics. PERL, well, don’t get me started on PERL.
My frustration is that, after 40 years of computer language design, this still isn’t obvious. Any language design should have a non-onerious method for the programmer to state his or her intentions and those intentions can be verified before you actually try executing the bits. Our focus should be on finding light-weight methods for expression of complex intentions not in making the latest light-weight language that has the problems of it’s predecessors.