I'm afraid I'll have to blacklist you from the software development community if you continue to refer to Java and Perl as "niche" technologies. They're wildly popular, regardless of your taste for them.
When you're going 5000 mph, the likelihood for something going wrong shoots up. The likelihood for something going wrong killing everybody stays the same: really damn high.
You can access private fields/methods in Java with reflection and a modified policy file. This is done by modifying your policy file (granting ReflectPermission or something), and calling setAccessible(true) on the Field and Method objects you want to invoke.
On a side note, this is the worst idea I've ever heard.
Everyone knows documentation is crucial for code readability and maintainability. Strong typing, aside from letting the compiler catch countless developer goof-ups, is an invaluable tool for good documentation. Documentation is not just overarching system descriptions or code comments. In my opininon, another _crucial_ element of documentation is the code itself. But code can only be effective as documentation when it is thoughfully designed. I find that in a well designed system, the method signature says a vast majority of what you need to know about it. The name of the method, when considered with the name of the class it is in, should give you a very good idea of what this method does. The return type, parameters, and declared exceptions should further clarify what this method does and how it does it. Of course you'll need code comments to clarify the finer points, but if you need explicit documentation to describe _what the method does_, you should be more thoughtful about the design. That being said, strong types are crucial. They allow me to specify _exactly_ what I want you to pass to my method, and _exactly_ what I will return. This "forced contract" is what allows huge systems to evolve. In a weakly typed system, you can document this same behavior until your face turns blue, but the compiler won't warn you when your documentation is out of date.
Slashdot Mirror
I think it would destroy my soul to work there.
I'm afraid I'll have to blacklist you from the software development community if you continue to refer to Java and Perl as "niche" technologies. They're wildly popular, regardless of your taste for them.
Do you HAVE to have a funny name to work at MSN Search?
When you're going 5000 mph, the likelihood for something going wrong shoots up. The likelihood for something going wrong killing everybody stays the same: really damn high.
You can access private fields/methods in Java with reflection and a modified policy file. This is done by modifying your policy file (granting ReflectPermission or something), and calling setAccessible(true) on the Field and Method objects you want to invoke.
On a side note, this is the worst idea I've ever heard.
Everyone knows documentation is crucial for code readability and maintainability. Strong typing, aside from letting the compiler catch countless developer goof-ups, is an invaluable tool for good documentation. Documentation is not just overarching system descriptions or code comments. In my opininon, another _crucial_ element of documentation is the code itself. But code can only be effective as documentation when it is thoughfully designed. I find that in a well designed system, the method signature says a vast majority of what you need to know about it. The name of the method, when considered with the name of the class it is in, should give you a very good idea of what this method does. The return type, parameters, and declared exceptions should further clarify what this method does and how it does it. Of course you'll need code comments to clarify the finer points, but if you need explicit documentation to describe _what the method does_, you should be more thoughtful about the design. That being said, strong types are crucial. They allow me to specify _exactly_ what I want you to pass to my method, and _exactly_ what I will return. This "forced contract" is what allows huge systems to evolve. In a weakly typed system, you can document this same behavior until your face turns blue, but the compiler won't warn you when your documentation is out of date.
http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.ht ml