Re: Perl or Python?

[Aleksey Cheusov <vle@gmx.net>]

>  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: <cht8q-6kG-9@gated-at.bofh.it> (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)