Здравствуйте, Cyberax, Вы писали:

C>И является замечательным источником ошибок на больших проектах, особенно
C>тех, которые пишут неквалифицированные программисты....

Программирование это вообще источник ошибок. В форумах, мэйллистах и news группах подобные дискуссии обычно оканчиваются тем, что люди соглашаются на следующем:
1) Статическая проверка типов увеличивает количество ошибок, пойманное до тестирования.
2) Статическая типизация позволяет генерировать более эффективный код.
3) Последствия отсутствия статической проверки типов а ассемблере, FORTH, и С гораздо хуже, чем в языках Smalltalk, JScript и Python. Ошибки типизации в С обыкновенно ведут к повреждению памяти, что невозможно в перечисленных языках — они проверяют типы в рантайме.
4) Часть людей считает, что явная аннотация типов является неотемлемой и критичной частью их подхода к программированию, и что время, потраченное на это, окупается сокращением времени отладки, тестирования, и сопровождения.
5) При этом, другие люди уверены в том, что аннотации типов замусоривают код и делают программы менее гибкими, что удлинняет фазу прототипирования и затруднят экcперименты.

Также, неплохо иметь в виду, что:
1) Определение типов возможно без аннотации типов (пример — система типов Хиндли-Милнера, которая гарантирует определение типа из контекста). Такая техника называется type inference, и применяется во многих, как статически, так и динамически типизированных языках, в частности, в JScript.NET.

2) Также, многие динамически типизированные языки разрешают явную аннотацию типов. Как например JScript.NET.

3) Вышеперечисленное позволяет динамически типизированным языкам, вопреки распространенному мнению, достигать высокой производительности сравнимой с С# и Java а также выявлять ошибки типизации до тестирования (но не обязательно во время компиляции — часто это делается отдельными тулзами).

4) Динамическая типизация не более опасна, чем явное использование динамического приведения типов в языках Java и C#. Техника программирования, подразумевающая использование QueryInterface (в COM) и вообще динамических запросов интерфейсов (в Java и C#) не имеет такой "убийственной" репутации, как динамическая типизация, хотя совершенно ей эквивалентна. На самом деле тот же С# позволяет писать динамически типизированный код, только он будет выглядеть более громоздко. У вас используется тип Object? Вы запрашиваете у объекта интерфейс? Поздравляю, ваш код динамически типизирован.

5) Процесс разработки с применением динамически типизированных языков существенно отличается от такового для статически типизированных. Он в гораздо большей степени итеративен и ориентирован на прототипирование — естественно, в нем находят отражение сильные стороны динамически типизированных языков. В силу отличий процессов разработки ответ на вопрос о качестве не так однозначен. Поясню.

Цена исправления дефекта в среднем тем больше, чем больше прошло времени с его внесения до его обнаружения (по данным Carnegi-Mellon SEI). Таким образом, у нас ошибки типизации находятся позже, и возрастает цена их исправления. Однако, благодаря большей ориентированности цикла разработки на прототипирование, раньше находятся алгоритмические дефекты и дефекты дизайна (которые всегда стоят дороже ошибок типизации), и их исправление будет стоить дешевле. На деле эти два фактора нивелируют друг друга, что подтверждает...

6) ...практика написания больших систем на динамически типизированных языках без применения статических проверок типов. Она показывает, что наличие динамической типизации не влияет заметным образом на количество ошибок в конечной системе, и такие ошибки не являются критическим фактором при разработке. В частности, метрики Ericsson по закрытым проектам (среди которых есть проекты размером до 2.5 миллионов строк) показывают, что средняя плотность дефектов на тысячу строк кода в динамически типизированных языках (Erlang) практически не отличается от таковой для статически типизированных языков (Java, C++, PLEX).

Хао. Я все сказал. ИМХО, повода для флейма нет. Мне, например, все понятно .