> AC> Любое высказывание подобного рода всегда предполагает "при прочих > AC> равных". Нельзя сравнивать километры и килограммы. > > Так а не бывает "прочих равных". Строгая типизация не бесплатна не > только для разработчика компилятора, но и для программиста. Строгая типизация, даже частичная, как в Pike-е - это подарок и для транслятора и для программиста. Транслятору меньше работы по выводу типа из контекста и меньше работы по "хитрой" оптимизации, типа той, что делает Lisp. Программисту - больше проверок вылавливается compile-time. Это опять же азбука. "Многа букафф в слове string, набрать ниасилил" - не аргумент.
> AC> Из статической типизации не следует компилируемость языка, то есть > AC> длительной _предварительной_ компиляции. И наоборот. Из > AC> "компилируемости" языка не следует то, что он со статической > AC> типизацией. Lua, например умеет компилироваться в исполняемый шитый код > AC> (бинарь), но он динамический. Еще пример, для С, ЯП со статической > AC> типизацией, существуют интерпретаторы. > > Статическая типизация интересна только на стадии компиляции. Если код > интерпретируется, статическая типизация становится эквивалентна > динамической :-) Нет. Я не зря подчеркнул слово "предварительной". Почти все, наверное, нынешние трансляторы со всяких разных ЯП компилируют программу во внутреннее представление непосредственно перед запуском, отлавливая опечатки, синтаксические ошибки, несоответствия типов и прочее. > Хотя, конечно, JIT-компиляция разницу все же дает. JIT - это очень дорогая технология, придуманная для того, чтобы не работать над эффективным внутренним представлением (шитым кодом) :-) Часть пиара ;-) > Другое дело, что я вообще не очень понимаю смысл контроля _типов_ иначе > как в качестве "контроля значений для бедных". Для решения задачи нужно > контролировать _значения_. А отдельный контроль _типа_ имеет смысл > только тогда, когда динамический контроль значения (вместе с типом) - > слишком дорогое удовольствие. И тебе тот же ответ, run-time проверки очень дороги по сравнению с compile-time для любых более-менее крупных программ. По-моему это очевидно. А в словах int|string|float|map|set|function|object|mixed по-моему не так много букв, чтобы было лень их набрать. Про подарки смотри выше. > А если я могу себе позволить динамический контроль, то с какого перепугу > я буду его ограничивать контролем именно типа? Выше. > AC> Имеет. Динамические языки требуют на порядок большего количества > AC> тестов. Это и есть "цена" динамичности. > > Из вышеизложенного следует, что нифига не большего. Ровно такого же. Читать внимательно. Проверка соответствия типов в кусках кода, который не покрыт тестами дает _минимальную необходимую_ гарантию корректности этого куска кода. В случае ЯП с динамической типизацией (или ЯП, где, к примеру, не нужно декларировать переменные) даже такой минимальной проверки просто нет. Поэтому для таких ЯП нужно намного больше тестов. Собственно компиляция, или предварительная в бинарь или сразу при запуске - это и есть тест номер 1. > Потому что статического контроля для реальных задач совершенно недостаточно. Надевать обувь зимой при выходе на улицу совершенно недостаточно для того, чтобы не замерзнуть, но почему-то все ее надевают. Ты же матемак, а тут элементарная логика :-) > AC> То, что многие опенсорсники их не пишут, полагаяюсь исключительно > AC> на бетатестирование - это их проблемы. > > А вот функциональный подход - на порядок меньшего (позволяет декомпозицию > и тестов тоже). Угу, в проектах уровня hello world. И это, технологии формального доказательства правильности программ вполне развиты и для императивного подхода тоже. "Наука программирования" Д.Грис, самая популярная по-моему книга этого жанра. -- Best regards, Aleksey Cheusov. In-Reply-To: <[email protected]> (Artem Chuprina's message of "Thu, 19 Mar 2009 17:20:07 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
