A lot of these discussions are too focused on language syntax as if the compiler will solve all my problems. If only the language could check this, or prevent me from doing that, and so on. I don't think that anyone is stepping back and seeing the big picture here. It doesn't matter what the language checks or doesn't check, nobody would ever forget about engineering discipline, right? So, you implement walkthrus, reviews, and feedback between marketing, product management, design, construction, QA, support, documentation, and other groups to make sure that you have 1) solved the right problems, 2) have a quality and supportable implementation, and 3) that everyone is working from the same understanding. That said, the development team unit tests their code, and the QA team performs verification to the design materials. Even in an informal setting, nobody in their right mind would not test to verify behavior.
So, my worry is that a lot of these features, while syntactically interesting, do not really amount to a hill of beans. Are we making the language overly complex and essoteric for any net gain in the big picture? Combine that with the overwhelming use of modern IDE's and tools to check, cross-check, fill-in boiler-plate code, suggest alternatives, enforce stylistic standards, and to test the code, do we NEED the compiler to do any more? We have never needed these things in the past and have built major systems, with high levels of complexity and quality. Why now are these "problems" raising their heads?
Just because it is possible to do something does not mean that it is a good idea to do it. The compiler can't possibly save a programmer from doing something wrong. So, if the justification for these additions is to "protect the programmer" from making silly mistakes, then I suggest that this is a bad reason. There is a very old saying in software, "you can't make software foolproof because fools are so @&$% ingenious". That goes for languages too.
If you want to solve problems in the language, then lets try some of these:
1. Allow us to use an object reference in a switch, not just a primitive. Allow the case to be an expression instead of a constant.
2. Add serial I/O support that is portable across platforms and supports USB as well as traditional serial devices.
3. Add cross-language capabilities so that we don't always have to build our own bridges in JNI
4. Adopt SWT as another GUI standard. It can coexist with Swing! It's just another tool in the toolbox.
5. Add labeled breaks and continues. That would allow me to jump out of nested loops to any level in one statement rather than adding bizarre logic to detect when to break out.
I'm not posting this message to suggest any specific changes, although I could. There are other features and capabilities that could be of value to a developer. However, of these, only a very small amount would be language changes. Almost all are added support, additional packages and implementations, etc.
The java language (at 1.4 level) is a great language. As it stands, the language itself is very mature, and needs very little tweeking. The problem that I see is one of it being a mature product. As a product develops, it is basically a clean slate. Allmost all of the input is from every level of user of the product. As the product matures, the users that are getting their needs met stop being vocal, and the "majority" of the comments are being generated by the "minority" of the users. So, as a product matures, it is extremely important to make sure that you are not getting driven by a vocal minority, that will cause you to loose your silent majority. Also, the silent majority had better not remain silent, or else this is exactly the outcome that will happen! |
java.net RSS Feeds
