Каковы преимущества (и недостатки) языка со слабым контролем типов?
Я - большой поклонник PHP, и это - очевидно, язык очень со слабым контролем типов. Я понимаю, что некоторые преимущества включают общую независимость изменения тип переменных на лету и такого.
О чем я задаюсь вопросом, недостатки. Что можно выйти из языка со строгим контролем типов как C, который Вы иначе не можете получить от со слабым контролем типов как PHP? Также с установкой типа (как двойной ($variable)), можно было утверждать, что даже язык со слабым контролем типов может действовать точно так же, как со строгим контролем типов.
Так. Слабый тип. Каковы некоторые преимущества, которые я не включал? Что еще более важно, каковы недостатки?
5 ответов
Приведенное преимущество статической типизации заключается в том, что существуют целые классы ошибок, отлавливаемых во время компиляции, которые не доходят до времени выполнения. Например, если у вас есть статически типизированный класс или интерфейс в качестве параметра функции, то вы не сможете случайно передать объект неправильного типа (без явного и неправильного приведения, то есть).
Конечно, это не помешает вам передать неправильный объект правильного типа или реализацию интерфейса, где вы дали ему правильные функции, но они делают неправильные вещи. Более того, если у вас 100% покрытие кода, как, скажем, у людей из PHP/Python/etc, то какая разница, отлавливаете ли вы ошибку во время компиляции или во время выполнения?
Лично мне было весело в языках со статической типизацией и весело в языках без нее. Это редко является решающим фактором, поскольку мне никогда не приходилось выбирать между двумя одинаковыми языками, кроме типа типизации, и обычно есть более важные вещи, о которых стоит беспокоиться. Я обнаружил, что при использовании статически типизированных языков я намеренно "опираюсь на компилятор", пытаясь написать код таким образом, что если он неправильный, то он не скомпилируется. Например, есть определенные рефакторы, которые можно выполнить, внеся изменения в одном месте, а затем исправить все ошибки компиляции, которые возникнут в результате, и повторять до тех пор, пока не скомпилируется чистый код. Делать то же самое, выполняя полный набор тестов несколько раз, может быть не очень практично. Но нет ничего необычного в том, что IDE автоматизируют те же рефакторы в других языках, или что тесты выполняются быстро, так что это вопрос удобства, а не возможности.
Люди, которые имеют законное беспокойство, помимо удобства и предпочтения стиля кодирования - это те, кто работает над формальными доказательствами корректности кода. Мое невежественное впечатление таково, что статическая дедукция типов может делать большую часть (но не всю) работы, которую делает явная статическая типизация, и экономит значительный износ клавиатуры. Так что если статическая типизация заставляет людей писать код так, чтобы его было легче доказать, тогда в этом может быть что-то от POV. Я говорю "если": Я не знаю, и не похоже, что большинство людей доказывают свой статически типизированный код в любом случае.
изменение типов переменных на лету и тому подобное
Я думаю, что это сомнительная ценность. Всегда так заманчиво сделать что-то вроде (Python/Django):
user = request.GET['username']
# do something with the string variable, "user"
user = get_object_or_404(User,user)
# do something with the User object variable, "user"
Но действительно, должно ли одно и то же имя использоваться для разных вещей внутри функции? Возможно. Скорее всего, нет. "Повторное использование", например, целочисленных переменных для других вещей в статически типизированных языках также не слишком поощряется. Желание не думать о кратких, описательных именах переменных, вероятно, в 95% случаев не должно преобладать над желанием иметь однозначный код...
Btw, обычно слабая типизация означает, что неявные преобразования типов имеют место, а сильная типизация означает, что нет. Согласно этому определению, C слабо типизирован в том, что касается арифметических типов, поэтому я предполагаю, что вы имеете в виду не это. Я думаю, широко распространено мнение, что полная сильная типизация скорее мешает, чем помогает, а "полная слабая типизация" (все можно преобразовать в любое другое) в большинстве языков бессмысленна. Поэтому вопрос заключается в том, сколько и каких неявных преобразований можно допустить, прежде чем ваш код станет слишком сложным для понимания. См. также, в C++, постоянную трудность в принятии решения о реализации операторов преобразования и неявных одноарговых конструкторов.
Об этом написано много книг. Есть неизбежный компромисс; со слабо типизированным языком многие неприятности просто перестают быть. Например, в Python вам никогда не придется беспокоиться о разделении float на int ; добавление типизация аргументов функций (знаете ли вы, что в OCaml есть специальные операторы +. Для добавления int в список ; float s потому что (+) отправляет int s на int s!); забывая, что переменная может иметь значение NULL ... такого рода проблемы просто исчезают.
На их место приходит целый ряд новых ошибок времени выполнения: Python [0] * 5 выдает, подождите, [0,0,0,0,0] ! OCaml, несмотря на все неудобства строгой типизации, отлавливает множество много ошибок с помощью своего компилятора; и именно поэтому это хорошо. Это компромисс.
Прямо из Википедии:
Заявленное преимущество слабого набора текста в том, что для этого требуется меньше усилий часть программиста, чем сильная печатать, потому что компилятор или интерпретатор неявно выполняет определенные виды конверсий. Тем не мение, один заявленный недостаток заключается в том, что слабо типизированные системы программирования ловят меньше ошибок во время компиляции и некоторые из них могут остаться после тестирование завершено.
Я бы сказал примерно то же самое. Однако остерегайтесь относительной неоднозначности этих терминов («строгая типизация» и «слабая типизация»), поскольку неявные преобразования стирают черту.
Слабый и Сильный - нагруженные термины. (Вы хотите быть программистом со слабым языком?) Динамический и статический лучше, но я могу представить, что большинство людей предпочли бы быть динамическим программистом, чем статическим. Я бы назвал PHP беспорядочным языком (это не загруженный термин;))
PHP:
garbage_out = garbage_in * 3; // garbage_in was not initialized yet
"hello world" + 2; // does this make sense?
Разрешение неинициализированных переменных очень затрудняет поиск ошибок из-за орфографических ошибок. Разрешение операций с несвязанными типами также почти всегда является ошибкой, о которой следует сообщать. Большинство интерпретируемых динамических языков не позволяют этого по уважительной причине. Вы можете иметь динамически типизированный язык, не допуская мусора.
См. эту таблицу, показывающую результаты применения оператора PHP == к парам пустых или других основных значений различных типов, таких как 0, "0", NULL и """. Оператор некоммутативен, и таблица, мягко говоря, неинтуитивна. (Справедливости ради, не то чтобы имело большой смысл спрашивать, равна ли строка массиву - но вы можете сделать это в слабо типизированном языке, что и является подводным камнем, и да поможет вам Тьюринг, если язык попытается вам "помочь")