Aleksey Cheusov -> Debian-Russian2 @ Thu, 19 Mar 2009 17:38:17 +0200: >>> Pike, например, язык динамический и безопастный, но в то же время >>> допускает типизированные переменные, и он не сегфолтится. >>> Вспоминаем логику и выражение "при прочих равных условиях". >>> Не надо сравнивать C и скриптовые языки. >> >> Вы заявляли выше, что строгая типизация обеспечивает надежность >> программ. AC> Любое высказывание подобного рода всегда предполагает "при прочих AC> равных". Нельзя сравнивать километры и килограммы.
Так а не бывает "прочих равных". Строгая типизация не бесплатна не только для разработчика компилятора, но и для программиста. Особенно - когда таки надо работать с коллекцией разнотипных данных... AC> vulnerabilities. В-четвертых, у моих знакомых есть ОЧЕНЬ AC> отрицательный опыт написания БОЛЬШОЙ программы на тикле (у меня AC> такого опыта нет). Не то, чтобы это аргумент, но success story я бы AC> это не назвал. Ну а у Печникова, вон, есть очень положительный. Правда, при том, как он там, по его словам, использует SQL, мне страшно... >> Оказывается, чтобы создавать надежные программы, нужны динамические >> языки, и неважно, типизированы они или нет. AC> Нет, не оказывается. Полно крупных надежных программ, написанных на AC> java, C#, Ada, и прочих, которые динамическими не являются. AC> Надежные программы можно создать на любом языке, и на динамическом AC> и на статическом, вопрос только в цене. Так дело в том, что вопрос создания надежной программы - это именно вопрос цены. >>> > Ничего, кроме скорости выполнения и упрощения >>> > компилятора/интерпретатора типизация переменных не дает. >>> >>> Наглое и подлое вранье! Разницу между compile-time и run-time проверками >>> знаем? А разницу в "цене" этих проверок? >> >> И что эта разница дает, кроме скорости выполнения кода и упрощения его >> компиляции/интерпретации? AC> Из статической типизации не следует компилируемость языка, то есть AC> длительной _предварительной_ компиляции. И наоборот. Из AC> "компилируемости" языка не следует то, что он со статической AC> типизацией. Lua, например умеет компилироваться в исполняемый шитый код AC> (бинарь), но он динамический. Еще пример, для С, ЯП со статической AC> типизацией, существуют интерпретаторы. Статическая типизация интересна только на стадии компиляции. Если код интерпретируется, статическая типизация становится эквивалентна динамической :-) Хотя, конечно, JIT-компиляция разницу все же дает. Другое дело, что я вообще не очень понимаю смысл контроля _типов_ иначе как в качестве "контроля значений для бедных". Для решения задачи нужно контролировать _значения_. А отдельный контроль _типа_ имеет смысл только тогда, когда динамический контроль значения (вместе с типом) - слишком дорогое удовольствие. Т.е. там, где я пишу на C и подумываю об ассемблере - там да, имеет смысл. Там я ради ускорения выполнения иду на отсутствие контроля в рантайме. Там данные будут интерпретироваться так, как я сказал. И вот чтобы хоть как-то отследить мои ошибки, я прошу компилятор проконтролировать хотя бы объявленные типы. А если я могу себе позволить динамический контроль, то с какого перепугу я буду его ограничивать контролем именно типа? Мне, вообще-то, важно не только то, что это температура, но и что эта температура измерялась там же, где и вон то давление. Или что это не просто позиция, а позиция от этого буфера. >> и к надежности отношения не имеет. AC> Имеет. Динамические языки требуют на порядок большего количества AC> тестов. Это и есть "цена" динамичности. Из вышеизложенного следует, что нифига не большего. Ровно такого же. Потому что статического контроля для реальных задач совершенно недостаточно. AC> То, что многие опенсорсники их не пишут, полагаяюсь исключительно AC> на бетатестирование - это их проблемы. А вот функциональный подход - на порядок меньшего (позволяет декомпозицию и тестов тоже). -- Artem Chuprina RFC2822: <ran{}ran.pp.ru> Jabber: r...@jabber.ran.pp.ru -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org