Some comments:

Open development of Java is a recent addition.
Python also supports procedural style programming.
If you find yourself writing getters and setters in Python think again. They are not needed.

Java's manifest static typing means that you have to give the correct type to every variable, even when it would be straight forward for a compiler to calculate the type of some variables. Some of the type errors that Java's compiler reports are due to you having to duplicate type information that the compiler then has the algorithms to check and state are wrong! Other statically typed languages (Haskel, i think), need you to add only minimal type information and then can compute the types of other variables.

If I do:
a = b;
then a must have b's type (putting it very simply), so why explicitely declare the type of a?
As you can see from your examples, given a fixed problem a Java solution tends to be large and complex. adding type information does not make the solution more readable, or more maintainable than a more succinct solution. Because Java solutions are largerthey rely more heavily on IDE's which, in turn, allow you to write larger solutions and 'manage' the incorporation of larger, verbose libraries... You can spiral away into bloated code until you reach your IDE's limits.

Your static vs dynamic conclusion weights the static case too much, given your arguments.

On efficiency: Often dynamic languages give you time to write, discover if the solution is efficient and re-code with another algorithm, in the time it would take to produce a single Java solution.You don't mention the memory footprint of Java solutions, or that the increased time you have to modify an algorithm can give much better results than compiling a worse one; or that the routine use of optimised higher order datatypes such as dictionaries or hashes can lead to faster, cleaner code.
I'd also add the command line shell available to Python/Ruby programmers can greatly aid in efficiency - often allowing the mock-up of an early solution with a customer making sure that what you think the customer asked for is what the customer wants.

IDE's/Tools/Libraries: How could you not give the advantage to Python/Java! They are scripting languages! What this means is that those 'Java' libraries are Jython/JRuby libraries. moreover, those .NET libraries are IronPython/IronRuby Libraries; those Boost C++ libraries are CPython libraries.... I've heard people dismiss this aspect of dynamic languages before, but it ccan be used to great effect.

Your section 'We should not move to Python/Ruby completely because' is pure Java FUD:
* No compile-time type information
- Of course not. They are dynamic!
* Still not mature enough
- I thought Python was of a similar age to Java?
* Tools not good enough
- Could equally be said that Java needs its IDE's to prop-up bad language design.
* Not being used in the mainstream.
- It is being used by cannier competitors :-)

And your last reason for advocating the use of Python/Ruby speaks volumes:
# Its fun to work on

- Happy programmers write better code. (Give me a pay rise).

- Paddy.

Its really sad that we as developers have not matured over the years and still follow languages as religions. I see this happening on almost every technical discussion forum. And this attitude is really holding us back as we just refuse to look at the issues in a pragmatic and constructive way. We simply resort to "my language is better than yours" mode with all the rhetoric force. I tried not doing that in my paper although I have been using Java for a long time and am pretty new to Ruby/Python. I did that because I genuinely feel that it is in my favour only and I dont want to win a "false" battle and loose the "real" war. Anyways, I would try to provide my opinion on some of your comments:

{Open development of Java is a recent addition.}
Open source community has been quite strong over the years in Java.

{Python also supports procedural style programming.}
Yeah! I mentioned that in my paper.

{If you find yourself writing getters and setters in Python think again. They are not needed.}
My simple class example (though in Ruby but represent both languages) doesnt use any getters/setters. And I dont like generating/writing them in Java at all. It was a big relief when I came to know that Python/Ruby doesnt need them.

{Java's manifest static typing means that you have to give the correct type to every variable, even when it would be straight forward for a compiler to calculate the type of some variables. Some of the type errors that Java's compiler reports are due to you having to duplicate type information that the compiler then has the algorithms to check and state are wrong! Other statically typed languages (Haskel, i think), need you to add only minimal type information and then can compute the types of other variables.
If I do:a = b;then a must have b's type (putting it very simply), so why explicitely declare the type of a? }

Completely agree with you on this point. It is not required at all. But, as I mention in the paper, you need type information in some case, and you dont need it in others, especially when it is just repeating the information and a compiler can easily know the type even without mentioning it. Java says declare all, Python/Ruby says declare none. We need a middle way. Even in your example at least b must have a declared type to increase the clarity.

{As you can see from your examples, given a fixed problem a Java solution tends to be large and complex. adding type information does not make the solution more readable, or more maintainable than a more succinct solution. }

It does make a difference. Take an example of operator overloading in Python/Ruby. If I write:
object1 = object2 + object3
Its simply ambiguous. I have no way to know whats happening coz I dont have the type information.

{Because Java solutions are largerthey rely more heavily on IDE's which, in turn, allow you to write larger solutions and 'manage' the incorporation of larger, verbose libraries... You can spiral away into bloated code until you reach your IDE's limits. }
Agree with that.

{Your static vs dynamic conclusion weights the static case too much, given your arguments.}
That my opinion based on my prejudices :). Constructive criticism is welcome!

{On efficiency: Often dynamic languages give you time to write, discover if the solution is efficient and re-code with another algorithm, in the time it would take to produce a single Java solution.}
I mentioned that in in "Productivity". But refactoring is much easier in Java as tools require compile time type info for better refactoring support.

{You don't mention the memory footprint of Java solutions, or that the increased time you have to modify an algorithm can give much better results than compiling a worse one; or that the routine use of optimised higher order datatypes such as dictionaries or hashes can lead to faster, cleaner code.}
You might be right, I didnt go into that detail.

{I'd also add the command line shell available to Python/Ruby programmers can greatly aid in efficiency - often allowing the mock-up of an early solution with a customer making sure that what you think the customer asked for is what the customer wants.}
Dont tell me your customer would use the command line! I would do that following an iterative development process independent of the language used and give the system with GUI to the customer to play with.

{IDE's/Tools/Libraries: How could you not give the advantage to Python/Java! They are scripting languages! What this means is that those 'Java' libraries are Jython/JRuby libraries. moreover, those .NET libraries are IronPython/IronRuby Libraries; those Boost C++ libraries are CPython libraries.... I've heard people dismiss this aspect of dynamic languages before, but it ccan be used to great effect.}
I am sorry, I wont be using Python, Jython, CPython and IronPython at the same time. Anyways, I could not find any good IDE for Pyhton comparative to Eclipse/IntelliJ.

{Your section 'We should not move to Python/Ruby completely because' is pure Java FUD:}
Its your opinion. I beg to differ.

{* No compile-time type information- Of course not. They are dynamic!}
But I need type info at some places to increase readability and more importantly to increase tools/IDE support. As I am pampered by Eclipse and cant code without sophisticated tools:)

{* Still not mature enough- I thought Python was of a similar age to Java?}
Being aged doesn't essentially means you are mature. Python doesn't even have complete Language Specifications. Do I need to mention anything else? You really cant be serious while comparing it with Java on that aspect.

{* Tools not good enough- Could equally be said that Java needs its IDE's to prop-up bad language design.}
Right and wrong. It does that at several places but it compliments the language beautifully at others. Anyways, I need tools to be productive and to enjoy coding.

{* Not being used in the mainstream.- It is being used by cannier competitors :-)}
Using mainstream languages has so many advantages. It matters!

{And your last reason for advocating the use of Python/Ruby speaks volumes:# Its fun to work on}
Yeah, I enjoyed playing with it. But delivering the solutions and providing business value to the customer are more important to me.

{- Happy programmers write better code. (Give me a pay rise).>
Agreed! But I don't know why we are so much language centric and "developer happiness" centric in software industry that we don't pay enough attention to being "solution" centric and "customer" centric. After all, the primary motive for writing code is to solve a business problem and not coder's happiness.

Anyways, thanks for the comments!

"Anyways, thanks for the comments!"

- Thank _you_ for the considered replies :-)

- Paddy.