Cтатика

топ 100 блогов love5an09.08.2010 Написал сейчас интерфейс битовых векторов для своего нового проекта на CL (библиотека различных алгоритмов сжатия/распаковки. Сейчас для CL, насколько я понимаю, есть только salza2, и там только DEFLATE и она только архивирует)(примерный набросок кода: http://paste.lisp.org/display/113332).

И задумался, в очередной раз, о статической типизации.

Какие compile-time гарантии она дает? Да крайне небольшие. Гарантии того порядка, что наш код не будет умножать бананы на тапки. Но ведь и так, кто в здравом уме это вообще будет делать?

А вот пример того, чего в моем коде(см. выше) действительно хотелось бы гарантировать: чтобы внутренние счетчики битового потока всегда были в соответствующих границах - чтобы счетик битов не выходил бы за пределы 7, а счетчик байтов - за пределы внутреннего буфера.

Такое способны гарантировать только сложнейшие системы зависимых типов(dependent types). Но мне плохо становится от осознания необходимого количества расставленных по всему коду "гарантий"(в виде if'ов и подобного), и от оверхеда, который они принесут.

А как насчет других потенциальных ошибок? Как статическая типизация может нам гарантировать "целостность" потока? А именно, то, что между вызовами функций записи в поток, его счетки не поменяются так, что в результирующем буфере окажется мусор? Никак! От этого спасет только модульность, инкапсуляция.

И таких ошибок, которые типизации ортогональны - большинство. Причем, подавляющее.
Другое дело - оптимизация, но тут подход, используемый в CL - опциональные декларации типов, кажется мне оптимальным. При соответствующих декларациях, тот же SBCL способен выдать _очень_ эффективный код.

В контексте производительности результирующего кода можно, кстати, вспомнить еще один момент. А именно, когда при работе со статическими языками нам требуется динамика. Мы, естественно, можем ее в статических языках переизобрести. Но вот эффективность полученного, как в плане памяти, так и в плане производительности, в сравнении с кодом, генерируемым компиляторами того же Common Lisp - под огромным вопросом.

Так зачем же навязывать статику? Она лишает огромного множества потенциальных возможностей(или, как минимум, снижает эффективность реализации этих возможностей), привносит кучу трудностей и неудобств(разработка в таком же динамичном стиле, в каком она обычно происходит в CL или Python, в большинстве статических языков невозможна совсем не по причине отсутствия REPL(который, к тому же, кое-где и в них присутствует)), а взамен дает только мизерные гарантии и иллюзию корректности написанного кода(а бывает еще, и иллюзию производительности).

Оставить комментарий

Архив записей в блогах:
Начало здесь Продолжение здесь Сначала Генрих самоуверенно думал, что аннулирование брака не займет много времени - верный советник кардинал Уолси добудет соответствующее папское разрешение в кратчайшие сроки и представит его пред ясные королевские очи на блюдечке с голубой ...
Хочется написать пару слов про наш тепловозостроительный завод. Который сейчас испытывает очень нелегкую судьбу. И почему так получилось. Все разговоры о том, что сепаратисты вывезли все оборудование в Россию, а остальной пустили на металлолом, не имеют под собой никакого основания. Во ...
Заседания, совещания... Всё, как у больших. Результат? Злобная резолюция, которая скоро забудется. Потому как мир меняется, а давить на цивилизованные страны почти нечем. Скоро совсем нечем будет - спрос на углеводороды неизбежно будет и дальше падать. Прочёл однажды ...
Опасаюсь, как бы мои прогнозы о попытках ВСУ прорывов в ДНР не сбылись. Пока основная часть армии ДНР освобождает Мариуполь. Разминируют поля обычно перед наступлением. Военкор Котенок сообщает: "а вот это становится интересно — сразу из нескольких источников (в т.ч. боевых товарищей с ...
Экзамен Exam Собрать несколько незнакомых человек в замкнутом пространстве, поместить в условия разной степени экстремальности, ограничить во времени и средствах достижения цели ...