Re: Perl or Python?
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: ran@jabber.ran.pp.ru
Reply to: