Классический контр-аргумент сторонников типизации динамической - "модульные тесты наше всё". Вообще, Вашу идею можно обобщить до "автоматические средства проверки контрактов упрощают следование спецификации". Статическая типизация - лишь одно из таких средств, не самое мощное, но зачастую довольно удобное и лаконичное (другое средство - пресловутые модульные тесты, третье - явные контракты а-ля Eiffel). /Она же - одно из средств документации контрактов, опять же не самое мощное, но довольно удобное и лаконичное/
Классический контр-пример сторонников типизации статической: проверьте контрактами или юнит-тестами сложность алгоритма. Или штуку под названием "уникальность" (uniqueness в языке Clean, отсутствие более, чем одной ссылки на значение).
А вот статические системы типов это умеют. И это часть спецификации.
Так, здесь я отстал, увы :( Мой бэкграунд в этой области - в языках с достаточно бедными системами типов (С++ и иже). Если не лень, можно чуть подробнее про проверку сложности на основании статическской типизации? (или ссылку на "статью для дурака" - в смысле, человека, Haskell и подобные ему системы типов видевшего только из далека и давно)
"Уникальные типы" языка Clean позволяют протаскивать "уникальные значения," которые нельзя просто так скопировать и от которых нельзя просто так избавиться. Например, от внешнего мира (тип World) избавиться никак нельзя, он всегда присутствует в единственном экземпляре *World, а получить открытый файл и закрыть его можно только с использованием *World. Открытие имеет тип *World String -> (*World,*File), чтение *File Int -> (*File,String), запись *File String -> *File, а закрытие *File *World -> *World.
А я как раз сегодня тоже видел то ли у SPJ в эриксоновской презентахе, то ли у кого-то в блоге, что статическая типизация облегчает именно модификацию программы.
Не уверен, что правильно понял акцентировку. Если программист хорошо себе представляет, где и как используется изменяемый тип, он без труда внесет нужные изменения во все точки. Частая ситуация - когда он этого как раз не помнит. Вот тогда становится важным контроль типов времени компиляции, который часто может отловить куски кода, о которых программист забыл в процессе рефакторинга. То есть статическая типизация тут работает в качестве мета-информации о местах использования типов. Но эта информация бывает полезной и при изменениях в имплементации, не затрагивающих дизайна. Поэтому, мне кажется, и имеет смысл поставить на передний план именно этот эффект поддержки памяти человека при внесениях изменения в код.
Впрочем, мне на практике более важным преимуществом ст.комп. кажется обычная читаемость кода. Безо всяких аннотаций типа в коде очень легко заблудиться и потерять представление, какие значения может принимать та или иная переменная.
Меня больше интересовало, как построить контраргумент к "спецификация часто неправильна, чего ее протягивать во всю программу с помощью типов." Вроде, построил.
Грамотные команды с грамотными руководителями могут, допустим, на жабе написать что-то, соответствующее спецификации, допустим, даже написать "идеально" и "безглючно".
Проблемы начинаются в изменениях кода, соответствующих изменениям спецификации.
В идеальном варианте, который постепенно становится всё более реалистичным, код строится по спецификации автоматически, и остаётся "только" проблема чёткого, и главное, подробного, описания задачи.
> "Статическая типизация не гарантирует правильности изначальной спецификации." Одно другому не мешает. Проблему легко обойти, если использовать тег типа в данных (для интерпретируемых языков). При этом можно совмещать динамические типы и "условно-статические".
Объясняю. Вы заявили, что статическая типизация - имеет некий минус. А я вам возражаю, что этот минус надуманный: объявив переменную с заданным типом, можно легко гарантировать ее "правильность изначальной спецификации".
Это в том случае, если я вас правильно понял, так как судя по вашему ироничному тону, здесь могла бы возникнуть путаница в терминах (скажем так: страдает "изначальная спецификация типов").
Ага, понял. Я подумал, что ваш аргумент относится к динамической типизации (и в этом случае он ничего не доказывает).
Под неправильностью первоначальной спецификации я имел в виду просто ее (частичное) несоответствие требуемым целям. То есть, составили мы спецификацию, все написали, а оно - "не то," с разной степенью этого "не того."
Кстати, это применимо не только к статической типизации, но я решил, что есть смысл про это не упоминать, а просто рассмотреть вытекающий из минуса плюс.
Comments 13
Вообще, Вашу идею можно обобщить до "автоматические средства проверки контрактов упрощают следование спецификации". Статическая типизация - лишь одно из таких средств, не самое мощное, но зачастую довольно удобное и лаконичное (другое средство - пресловутые модульные тесты, третье - явные контракты а-ля Eiffel). /Она же - одно из средств документации контрактов, опять же не самое мощное, но довольно удобное и лаконичное/
Reply
А вот статические системы типов это умеют. И это часть спецификации.
Reply
Мой бэкграунд в этой области - в языках с достаточно бедными системами типов (С++ и иже).
Если не лень, можно чуть подробнее про проверку сложности на основании статическской типизации? (или ссылку на "статью для дурака" - в смысле, человека, Haskell и подобные ему системы типов видевшего только из далека и давно)
Reply
На зависимых типах выполняют проверку алгоритмов на предмет "влезет ли в память." Вот тут есть: http://www.dcs.st-and.ac.uk/~eb/index.php
"Уникальные типы" языка Clean позволяют протаскивать "уникальные значения," которые нельзя просто так скопировать и от которых нельзя просто так избавиться. Например, от внешнего мира (тип World) избавиться никак нельзя, он всегда присутствует в единственном экземпляре *World, а получить открытый файл и закрыть его можно только с использованием *World. Открытие имеет тип *World String -> (*World,*File), чтение *File Int -> (*File,String), запись *File String -> *File, а закрытие *File *World -> *World.
Reply
Reply
Reply
Впрочем, мне на практике более важным преимуществом ст.комп. кажется обычная читаемость кода. Безо всяких аннотаций типа в коде очень легко заблудиться и потерять представление, какие значения может принимать та или иная переменная.
Reply
Против всего остального возражений не имею. ;)
Reply
Грамотные команды с грамотными руководителями
могут, допустим, на жабе написать что-то,
соответствующее спецификации, допустим,
даже написать "идеально" и "безглючно".
Проблемы начинаются в изменениях кода,
соответствующих изменениям спецификации.
В идеальном варианте, который постепенно
становится всё более реалистичным, код
строится по спецификации автоматически,
и остаётся "только" проблема чёткого,
и главное, подробного, описания задачи.
Reply
Одно другому не мешает. Проблему легко обойти, если использовать тег типа в данных (для интерпретируемых языков). При этом можно совмещать динамические типы и "условно-статические".
Reply
Reply
Это в том случае, если я вас правильно понял, так как судя по вашему ироничному тону, здесь могла бы возникнуть путаница в терминах (скажем так: страдает "изначальная спецификация типов").
Reply
Под неправильностью первоначальной спецификации я имел в виду просто ее (частичное) несоответствие требуемым целям. То есть, составили мы спецификацию, все написали, а оно - "не то," с разной степенью этого "не того."
Кстати, это применимо не только к статической типизации, но я решил, что есть смысл про это не упоминать, а просто рассмотреть вытекающий из минуса плюс.
Reply
Leave a comment