Hello, msorc, you wrote: M> Well give we take last PHP and Python. In what on yours consists them ? I will not undertake to specify in a specific problem if to name finite not problem a dynamic essence most Python. But here something I did not see till now examples where it "correctly prepare". For simple scripts (within several hundreds code lines) - all is fine. And here when over the project start to work more than two-three persons, a rake begins. I worked in different large offices. In several places the Python for auxiliary tasks of type of tests was used and I yet did not see, that development on the Python transited so smoothly, as for statically-typed languages. Here now at us integration tests on the Python are written. All is perfectly structured and object-oriented, with the thought over inheritance hierarchy and good the code. It is direct "!" . Here it is fair. But it thus continually breaks from fresh . In 9 cases from 10 when I see fallen , I do not need to look at a specific error in a broad gull - simply I restart verification and it is normal from the second time transits. And it even +4 hours of waiting of result. Because, unlike Java, at any special checks the compiler does not do the code. Each change, in itself, looks correctly and the programmer who wrote the code, probably looked, whether is not present and even (it would be desirable to trust) launched the code before sending on the code-revju. But somewhere after merge of changes from several persons all time something breaks. Also happens so on some times in the course of the day. Plus, all is strongly aggravated with usage of web services - if the REST-inquiry parameter while the appropriate test will not be launched somewhere exchanged, anybody at all does not learn, whence it there is still caused. And errors each time - any unreadable barn from a heap "a wrong call __ init __" or still something suggesting despondency. Not, I, of course, agree - the passing on those messages and review last allows to find an error in some minutes, but by this moment is already lost N hours of waiting of results . The ten persons launched verification , waited 3. 5 hours to see the error report in which would be found at once in any language with static typification. And change API for languages with static typification too is much less painful - proxy classes and we see, where the compiler told about mismatch of parameters. And for the Python - we restart, we wait for 5 hours and we rake broad gulls. Someone once, many years ago, decided to write at us integration tests on the Python. And now anybody will not rewrite any more ten and hundred thousand code lines on the Python. It is necessary to suffer. At that, special pluses from such choice already also it is not visible. When code amount small the Python seems easier choice in respect of modifications. When it crosses rather small threshold of complexity, complexity of support of such code, in my opinion, where above.