> bad developing experience, code needs more debugging, it is harder to maintain and overall productivity is lower
All of these observations are highly subjective.
> Developing experience:
I much prefer developing in python than java. If IDEs factor in, there are a number available for python, none of which I use, because I find a simple editor is usually enough.
> code needs more debugging
That's a function of the problem and the developer. The run, check, edit cycle in python is a lot quicker than using your IDE to run, check, edit, compile. There are debuggers available for nearly every language that allow you to step and inspect.
> harder to maintain
Disagree. When you have code 1/5th (number pulled from my ass) the size codebase, maintainability can be much better. Unit testing helps, regardless of the language.
> productivity
A developer proficient in language [X] should be just as productive as a different developer proficient in language [Y]. Creating a massive type hierarchy of classes and interfaces is a tonne of overhead when you are trying to express a simple idea. In a language like python, you might write a simple class (or two), and use dynamic typing appropriately. A java developer may use code generation and IDE shortcuts to lessen the amount of total code they have to write though.
The advantages and disadvantages of dynamic and statically typed languages are fairly well known. Neither is perfect all the time and for each person. Just because you don't like dynamic languages, it does not mean they don't have their virtues.
[1]: http://www.amazon.com/Real-World-Functional-Programming-With...
tl;dr -- Composition is to functional programming as inheritance is to OO programming.
I started Typescript by subclassing but as I work more and more with it, I subclass less and less, and delegate more and more.
Static languages (usually) force you to use interfaces and sub-typing just so common code can be reused. Duck typing is a much nicer way of working - without having to jump through seemingly unnecessary hoops. The situation is even worse when you code for testability. Things that really shouldn't have an interface now require one, so you can mock out the object appropriately. This is all avoided in a language with duck typing.
This is actually where Go has a great impact. You get your static type checking without being forced to use explicit interfaces. It essentially uses duck typing for interface implementation.
You're free to enjoy static typing over dynamic typing all you like - but you shouldn't make the mistake of thinking dynamic typing is inferior in any way. It is different - just like imperative vs functional is different. You make a series of tradeoffs, that is all.
Protip: Try pudb. It will blow your mind.
Python is strongly typed only for the basic scalar types. With objects and classes there are just objects that may or may not have certain bound functions and attributes. Duck-typing is mostly perfectly sufficient since any errors do come out in practice, and there's no need for interfaces or classes as unique types, but what would be really helpful would be to have Clojure-like multimethods where dispatching of a function is itself a function of the arguments given in. That would be what would most alleviate the problems that arise from everything being a object() in Python.
So regardless of whatever actually happens, to the tools, each Ruby function is just all dealing with unknown type parameter objects.
As a conclusion, Ruby has type, but has no way to utilize it. I think any other popular scripting language - such as Python, JS, Lua… are in same situation. V8 does speculative strong dynamic typing, but the those generated informations are completely useless to code-writing level tools.
Type [an]notations are also useful for compilers when generating performant code. But projects like pypy and V8 (javascript) show that a well written interpreter can do run-time analysis, and generate performant code, just like a static analysis.
1. Dynamically strongly typed, but typing is limited to primitive types. 2. So actually it's untyped for objects which is really needs type information. 3. As it lacks class/interface concept at all, type (an)notation is fundamentally impossible, type tracking is also impossible. 4. So lacks ability to offer type information to toolset.
You don't have automated tooling support on Javascript about type, and it will degrade your productivity. So big companies interested on JS platform, are all offering JS with type notation -
1. Google = Dart, 2. MS = TypeScript, 3. Mozilla = Emscripten(in very unique way!)
Furthermore, recent languages offer automatic type inference - Haskell, Go, C++11. They force to retain type information, but also permit to elide them where accurately inference-able/deduce-able.
This is completely different with not forcing type notion such as Python, Ruby, Lua, JS. In these languages, it is fundamentally impossible to track complete type information. But in explicitly type notated languages, it's possible to track complete type informations even they're elided.
I think those type-(notation)-less languages are making some efforts to offer type informations by adding annotations. But I don't think that's really meaningful, because that's not enforced, and community doesn't care much.
> code needs more debugging, it is harder to maintain and overall productivity is lower
References?
Check the Dropbox's pain presentation: https://www.dropbox.com/s/83ppa5iykqmr14z/Py2v3Hackers2013.p...
1. https://docs.google.com/file/d/0B5C1aVVb3qRONVhiNDBiNUw0am8/...