динамическая типизация лучше чем строгая
Динамическая типизация C
Преамбула
Эта статья была написана и опубликована мной на своем сайте более десяти лет назад, сам сайт с тех пор канул в лету, а я так и не начал писать что-то более вразумительное в плане статей. Все ниже описанное является результатом исследования C как языка двадцатилетним парнем, а, следовательно, не претендует на звание учебного пособия, несмотря на стиль изложения. Тем не менее, я искренне надеюсь, что она побудит молодых разработчиков погрузиться в эксперименты с C также, как когда-то делал это я.
Предупреждение
Эта короткая статья, окажется абсолютно бесполезной для опытных программистов C/C++, но кому-то из начинающих, возможно, позволит сэкономить время. Хочу подчеркнуть, что в большинстве хороших книг по C/C++ данная тема рассмотрена в достаточной степени.
Динамическая и статическая типизация
Здесь мы поговорим про язык C, хотя все, что описано ниже, применимо и к C++.
Магия указателя пустоты
Вывод:
Первый пример не нес никакой полезной нагрузки. Попробуем ее поискать во втором примере:
Вывод:
Здесь мы создали, можно сказать, универсальную функцию для округления как целых чисел (которым оно не требуется, конечно), так и для чисел двойной точности. Следует понимать, что функция может выполнять и что-то более полезное, в зависимости от типа аргумента.
Альтернативная реализация функции lilround() :
Предположим, что у нас две или более структур ( struct ), которые содержат различный набор полей. Но так уж получилось, что нужно передать их одной и той же функции. Почему так вышло рассуждать не будем.
То все сработает корректно. Но если написать так:
То программа соберется, но во время работы выдаст неверный вариант, так как, в зависимости от того — к какой структуре приведем указатель, в случае обращения программа попытается считать первый байт из double value или, вообще, неизвестно откуда.
А вот и пример использования такого подхода:
Примечание: директивы компилятора #pragma pack(push, 1) и #pragma pack(pop) необходимо помещать до и после каждой специфической структуры, соответственно. Данная директива используется для выравнивания структуры в памяти, что обеспечит корректность метода. Однако не стоит также забывать о порядке полей.
В теле функции аргумент приводится к структуре iStruct и проверяется значение поля type. Дальше уже аргумент приводится к другому типу структуры, если нужно.
Исходя из кода: для совершения операции необходимо записать (*(int *)var) и уже к данной записи применить требуемый оператор.
Подобие интерфейсов в C
Вернемся к структурам. Если структура «засылается» далеко и глубоко в код, возможно даже чужой, то имеет смысл передать вместе с ней и методы, которые будут обрабатывать ее значения. Для этого создадим дополнительную структуру, которая заменит поле type :
Опишем реализации указанных выше функций для разных типов структур, а также — функции инициализации. Результат ниже:
Вывод:
Примечание: директивами компилятора следует обрамлять только те структуры, которые необходимо использовать в качестве аргумента для void-указателя.
Заключение
В последнем примере можно заметить сходство с ООП, что, в общем-то, правда. Здесь мы создаем структуру, инициализируем ее, задаем ее ключевым полям значения и вызываем функцию округления, которая, кстати говоря, крайне упростилась, хотя мы сюда же добавили вывод типа аргумента. На этом все. И помните, что применять подобные конструкции нужно размумно, ведь, в подавляющем большинстве задач их наличие не требуется.
UPD.: Спасибо модераторам хабра за указания на опечатки и досадные ошибки исходной версии текста.
Что такое типизация в программировании
Объясняем, что это такое, какая бывает типизация и на что она влияет.
Если вы читали что-то о языках программирования, то наверняка не раз наткнулись на упоминание типизации. Что это такое и что об этом нужно знать, когда выбираешь язык программирования?
Типизация — это то, как язык распознаёт типы переменных. Типизация определяет, нужно ли вам писать тип, или язык «поймёт» его сам, и насколько свободно можно с типами работать: например, можно ли их менять.
В бэкграунде — программирование, французский язык, академическое рисование, капоэйра. Сейчас учит финский. Любит путешествия и Балтийское море.
А что такое типы?
В переменную можно записывать информацию, а тип переменной описывает, какая именно информация записана в переменной и что с ней можно делать.
Типы бывают разные и немного различаются в разных языках.
Зачем нужно знать о типизации?
От типизации зависит, как вам работается с языком, как он себя ведёт. Если вы знаете, какие выгоды или проблемы приносят разные виды типизации, вам легче будет выбрать язык.
Какая бывает типизация?
Слабая и сильная
Если у языка сильная типизация (её ещё называют строгой), это значит, что он требует, чтобы разработчики строго следовали правилам работы с типами: если вы обозначили что-то как целое число, будьте добры с ним работать как с целым числом.
Языки со слабой типизацией «добрее»: если вы решите прибавить число к тексту, они не будут ругаться, а попробуют сделать то, что вы просите. Правда, результат может быть не совсем таким, как вы планировали.
В JavaScript, языке со слабой типизацией, можно сложить строку с числом, например вот так:
И получить строку «21».
А в Java так сделать нельзя: появится ошибка.
Статическая и динамическая
Статическая типизация значит, что типы определяются на этапе компиляции. То есть ошибки в типах будут видны ещё до того, как программа запустится.
В языках с динамической типизацией типы определяются во время выполнения программы.
Так, в динамически типизированном языке у одной и той же переменной могут быть разные типы в разных частях программы, а в статически типизированном, если вы задали переменной тип string, у неё будет только тип string.
Например, в Python (динамическая типизация) можно сделать вот так:
И язык не будет возражать. В Java (статическая типизация) так сделать нельзя.
Явная и неявная
Ещё типизацию делят на явную и неявную. Когда типизация неявная, тип определяется сам в момент, когда вы записываете в переменную информацию.
Например, если в Python написать так:
Он прочитает, что вы записали в переменную b целое число, и определит b как integer (int).
Явная типизация значит, что тип переменной написан. Например, в С переменная записывается вот так:
Само по себе разделение типизации на явную и неявную не столь важно: в статически типизированных языках она почти всегда явная, а в динамически — неявная.
Как типизация влияет на работу с языком?
Важно учитывать, что типизация — далеко не единственный фактор, который влияет на скорость. Нельзя сказать, что все языки со статической типизацией быстрее языков с динамической.
В каких языках какая типизация
Напоследок — типизации некоторых популярных языков:
Если вы пока новичок в программировании, то приглашаем вас на наш курс «Python-разработчик». Потому что Python — один из лучших языков для начинающих, в том числе благодаря своей типизации. Он научит дисциплине в работе с переменными, но при этом не уморит долгой писаниной. В курсе расскажут подробнее о разных типах переменных и динамической типизации, научат работе с классами и объектами и познакомят с разными библиотеками.
Ликбез по типизации в языках программирования
Эта статья содержит необходимый минимум тех вещей, которые просто необходимо знать о типизации, чтобы не называть динамическую типизацию злом, Lisp — бестиповым языком, а C — языком со строгой типизацией.
В полной версии находится подробное описание всех видов типизации, приправленное примерами кода, ссылками на популярные языки программирования и показательными картинками.
Рекомендую прочитать сначала краткую версию статьи, а затем при наличии желания и полную.
Краткая версия
Языки программирования по типизации принято делить на два больших лагеря — типизированные и нетипизированные (бестиповые). К первому например относятся C, Python, Scala, PHP и Lua, а ко второму — язык ассемблера, Forth и Brainfuck.
Так как «бестиповая типизация» по своей сути — проста как пробка, дальше она ни на какие другие виды не делится. А вот типизированные языки разделяются еще на несколько пересекающихся категорий:
Примеры:
Статическая: C, Java, C#;
Динамическая: Python, JavaScript, Ruby.
Примеры:
Сильная: Java, Python, Haskell, Lisp;
Слабая: C, JavaScript, Visual Basic, PHP.
Примеры:
Явная: C++, D, C#
Неявная: PHP, Lua, JavaScript
Также нужно заметить, что все эти категории пересекаются, например язык C имеет статическую слабую явную типизацию, а язык Python — динамическую сильную неявную.
Тем-не менее не бывает языков со статической и динамической типизаций одновременно. Хотя забегая вперед скажу, что тут я вру — они действительно существуют, но об этом позже.
Подробная версия
Если краткой версии Вам показалось недостаточно, хорошо. Не зря же я писал подробную? Главное, что в краткой версии просто невозможно было уместить всю полезную и интересную информацию, а подробная будет возможно слишком длинной, чтобы каждый смог ее прочесть, не напрягаясь.
Бестиповая типизация
В бестиповых языках программирования — все сущности считаются просто последовательностями бит, различной длины.
Бестиповая типизация обычно присуща низкоуровневым (язык ассемблера, Forth) и эзотерическим (Brainfuck, HQ9, Piet) языкам. Однако и у нее, наряду с недостатками, есть некоторые преимущества.
Преимущества
Недостатки
Сильная безтиповая типизация?
Да, такое существует. Например в языке ассемблера (для архитектуры х86/х86-64, других не знаю) нельзя ассемблировать программу, если вы попытаетесь загрузить в регистр cx (16 бит) данные из регистра rax (64 бита).
mov cx, eax ; ошибка времени ассемблирования
Так получается, что в ассемлере все-таки есть типизация? Я считаю, что этих проверок недостаточно. А Ваше мнение, конечно, зависит только от Вас.
Статическая и динамическая типизации
Главное, что отличает статическую (static) типизацию от динамической (dynamic) то, что все проверки типов выполняются на этапе компиляции, а не этапе выполнения.
Некоторым людям может показаться, что статическая типизация слишком ограничена (на самом деле так и есть, но от этого давно избавились с помощью некоторых методик). Некоторым же, что динамически типизированные языки — это игра с огнем, но какие же черты их выделяют? Неужели оба вида имеют шансы на существование? Если нет, то почему много как статически, так и динамически типизированных языков?
Преимущества статической типизации
Преимущества динамической типизации
Обобщенное программирование
Хорошо, самый важный аргумент за динамическую типизацию — удобство описания обобщенных алгоритмов. Давайте представим себе проблему — нам нужна функция поиска по нескольким массивам (или спискам) — по массиву целых чисел, по массиву вещественных и массиву символов.
Как же мы будем ее решать? Решим ее на 3-ех разных языках: одном с динамической типизацией и двух со статической.
Алгоритм поиска я возьму один из простейших — перебор. Функция будет получать искомый элемент, сам массив (или список) и возвращать индекс элемента, или, если элемент не найден — (-1).
Динамическое решение (Python):
Как видите, все просто и никаких проблем с тем, что список может содержать хоть числа, хоть списки, хоть другие массивы нет. Очень хорошо. Давайте пойдем дальше — решим эту-же задачу на Си!
Статическое решение (Си):
Ну, каждая функция в отдельности похожа на версию из Python, но почему их три? Неужели статическое программирование проиграло?
И да, и нет. Есть несколько методик программирования, одну из которых мы сейчас рассмотрим. Она называется обобщенное программирование и язык C++ ее неплохо поддерживает. Давайте посмотрим на новую версию:
Статическое решение (обобщенное программирование, C++):
Хорошо! Это выглядит не сильно сложнее чем версия на Python и при этом не пришлось много писать. Вдобавок мы получили реализацию для всех массивов, а не только для 3-ех, необходимых для решения задачи!
Эта версия похоже именно то, что нужно — мы получаем одновременно плюсы статической типизации и некоторые плюсы динамической.
Здорово, что это вообще возможно, но может быть еще лучше. Во-первых обобщенное программирование может быть удобнее и красивее (например в языке Haskell). Во-вторых помимо обобщенного программирования также можно применить полиморфизм (результат будет хуже), перегрузку функций (аналогично) или макросы.
Статика в динамике
Также нужно упомянуть, что многие статические языки позволяют использовать динамическую типизацию, например:
Сильная и слабая типизации
Языки с сильной типизацией не позволяют смешивать сущности разных типов в выражениях и не выполняют никаких автоматических преобразований. Также их называют «языки с строгой типизацией». Английский термин для этого — strong typing.
Слабо типизированные языки, наоборот всячески способствуют, чтобы программист смешивал разные типы в одном выражении, причем компилятор сам приведет все к единому типу. Также их называют «языки с нестрогой типизацией». Английский термин для этого — weak typing.
Слабую типизацию часто путают с динамической, что совершенно неверно. Динамически типизированный язык может быть и слабо и сильно типизирован.
Однако мало, кто придает значение строгости типизации. Часто заявляют, что если язык статически типизирован, то Вы сможете отловить множество потенциальных ошибок при компиляции. Они Вам врут!
Язык при этом должен иметь еще и сильную типизацию. И правда, если компилятор вместо сообщения об ошибке будет просто прибавлять строку к числу, или что еще хуже, вычтет из одного массива другой, какой нам толк, что все «проверки» типов будут на этапе компиляции? Правильно — слабая статическая типизация еще хуже, чем сильная динамическая! (Ну, это мое мнение)
Так что-же у слабой типизации вообще нет плюсов? Возможно так выглядит, однако несмотря на то, что я ярый сторонник сильной типизации, должен согласиться, что у слабой тоже есть преимущества.
Хотите узнать какие?
Преимущества сильной типизации
Преимущества слабой типизации
Оказывается есть и даже два.
Неявное приведение типов, в однозначных ситуациях и без потерь данных
Ух… Довольно длинный пункт. Давайте я буду дальше сокращать его до «ограниченное неявное преобразование» Так что же значит однозначная ситуация и потери данных?
Однозначная ситуация, это преобразование или операция в которой сущность сразу понятна. Вот например сложение двух чисел — однозначная ситуация. А преобразование числа в массив — нет (возможно создастся массив из одного элемента, возможно массив, с такой длинной, заполненный элементами по-умолчанию, а возможно число преобразуется в строку, а затем в массив символов).
Потеря данных это еще проще. Если мы преобразуем вещественное число 3.5 в целое — мы потеряем часть данных (на самом деле эта операция еще и неоднозначная — как будет производиться округление? В большую сторону? В меньшую? Отбрасывание дробной части?).
Преобразования в неоднозначных ситуациях и преобразования с потерей данных — это очень, очень плохо. Ничего хуже этого в программировании нет.
Если вы мне не верите, изучите язык PL/I или даже просто поищите его спецификацию. В нем есть правила преобразования между ВСЕМИ типами данных! Это просто ад!
Ладно, давайте вспомним про ограниченное неявное преобразование. Есть ли такие языки? Да, например в Pascal Вы можете преобразовать целое число в вещественное, но не наоборот. Также похожие механизмы есть в C#, Groovy и Common Lisp.
Ладно, я говорил, что есть еще способ получить пару плюсов слабой типизации в сильном языке. И да, он есть и называется полиморфизм конструкторов.
Я поясню его на примере замечательного языка Haskell.
Полиморфные конструкторы появились в результате наблюдения, что чаще всего безопасные неявные преобразования нужны при использовании числовых литералов.
И это сделано в Haskell, благодаря тому, что у литерала 1 нет конкретного типа. Это ни целое, ни вещественное, ни комплексное. Это же просто число!
Конечно спасает этот прием только при использовании смешанных выражений с числовыми литералами, а это лишь верхушка айсберга.
Таким образом можно сказать, что лучшим выходом будет балансирование на грани, между сильной и слабой типизацией. Но пока идеальный баланс не держит ни один язык, поэтому я больше склоняюсь к сильно типизированным языкам (таким как Haskell, Java, C#, Python), а не к слабо типизированным (таким как C, JavaScript, Lua, PHP).
Ладно, пойдем дальше?
Явная и неявная типизации
Язык с явной типизацией предполагает, что программист должен указывать типы всех переменных и функций, которые объявляет. Английский термин для этого — explicit typing.
Язык с неявной типизацией, напротив, предлагает Вам забыть о типах и переложить задачу вывода типов на компилятор или интерпретатор. Английски термин для этого — implicit typing.
По-началу можно решить, что неявная типизация равносильна динамической, а явная — статической, но дальше мы увидим, что это не так.
Есть ли плюсы у каждого вида, и опять же, есть ли их комбинации и есть ли языки с поддержкой обоих методов?
Преимущества явной типизации
Преимущества неявной типизации
Явная типизация по-выбору
Есть языки, с неявной типизацией по-умолчанию и возможностью указать тип значений при необходимости. Настоящий тип выражения транслятор выведет автоматически. Один из таких языков — Haskell, давайте я приведу простой пример, для наглядности:
* Спасибо int_index за нахождение ошибки.
Хм. Как мы видим, это очень красиво и коротко. Запись функции занимает всего 18 символов на одной строчке, включая пробелы!
Однако автоматический вывод типов довольно сложная вещь, и даже в таком крутом языке как Haskell, он иногда не справляется. (как пример можно привести ограничение мономорфизма)
Есть ли языки с явной типизацией по-умолчанию и неявной по-необходимости? Кон
ечно.
Неявная типизация по-выбору
В новом стандарте языка C++, названном C++11 (ранее назывался C++0x), было введено ключевое слово auto, благодаря которому можно заставить компилятор вывести тип, исходя из контекста:
Неплохо. Но запись сократилась не сильно. Давайте посмотрим пример с итераторами (если не понимаете, не бойтесь, главное заметьте, что запись благодаря автоматическому выводу очень сильно сокращается):
Ух ты! Вот это сокращение. Ладно, но можно ли сделать что-нибудь в духе Haskell, где тип возвращаемого значения будет зависеть от типов аргументов?
И опять ответ да, благодаря ключевому слову decltype в комбинации с auto:
Может показаться, что эта форма записи не сильно хороша, но в комбинации с обобщенным программированием (templates / generics) неявная типизация или автоматический вывод типов творят чудеса.
Некоторые языки программирования по данной классификации
Я приведу небольшой список из популярных языков и напишу как они подразделяются по каждой категории “типизаций”.
Возможно я где-то ошибся, особенно с CL, PHP и Obj-C, если по какому-то языку у Вас другое мнение — напишите в комментариях.
Заключение
Окей. Уже скоро будет светло и я чувствую, что про типизацию больше нечего сказать. Ой как? Тема бездонная? Очень много осталось недосказано? Прошу в комментарии, поделитесь полезной информацией.
Динамическая типизация — это не инструмент для разработки. Это чепуха (паршивая)
В программировании очень много вещей, в которых я разбираюсь очень плохо. Настолько много, что меня иногда спрашивают — а в чем ты вообще разбираешься?
Я разбираюсь в типах и проектировании удобного и надежного АПИ. Но для доброй половины разрабов эти вещи ничего не значат. Потому что они используют динамическую типизацию, и понятия не имеют, какие проблемы и зачем я решаю.
Большую часть жизни я просто махал на них рукой и проходил мимо. Эти глупцы не понимают очевидных вещей, и я не нанимался разъяснять каждому js-нику, почему его код — это не разработка, а игрушечное прототипирование. Но время идёт, а количество идиотов вокруг и не думает уменьшаться, вместо того, чтобы всей своей фронтенд индустрией переехать наконец на статический тайпскрипт, эти ослы начинают использовать всякие кложуры, писать тонны тестов, и идти на все мыслимые ухищрения — лишь бы не разбираться в типах.
В мире очень много спорных вещей, когда в зависимости от того, что ты хочешь получить, правда переваливается с одной чаши весов на другую, не оставляя место никакой абсолютной истине в последней инстанции. Пару лет назад я уже писал о типизации, но тогда я был молодой, глупый и трусливый — у меня была позиция, но чтобы не показаться идиотом, я старательно спрятал её за философскими рассуждениями о том, как все вокруг сложно, и как трудно работать адептам разных моделей типизации вместе.
Но сегодня я пришёл сюда, чтобы сказать:
Динамическая типизация — адское говнище, а инженеры которые верят в такой подход — серьезно ошибаются.
Противники статической типизации говорят, что все эти вещи не нужны. Они говорят мне, что
Баги, которые отлавливают типы, не стоят усилий, чтобы записать код этих типов.
Серьезно? Серьезно? Нам лень писать символы? Братан. Ты думаешь пять часов, а печатаешь десять минут. Ты инженер, так что попробуй посчитать, о каком эфорте ты говоришь. И не забудь, что со статической типизацией, или без нее, ты не раз в своей кодовой базе опишешь структуры объектов, с которыми будешь работать. Но если будешь пользоватся статикой, компилятор и IDE смогут делать эту работу за тебя. И проверять твой код на ошибки описания этих объектов. Если тебе лень писать аннотации типов к функциям — используй ЯП с выводом типов, или генерируй их с помощью расширений к IDE.
Если ты топишь, что аннотации раздувают кодовую базу — вспомни, блин, все наши принципы про то, что явное лучше неявного, что одна из важных задач кодовой базы — быть понятной и читаемой, как человеком, так и машиной. Если тебе лень проводить работу в своей тупой башке, чтобы понять на каких типах будет работать твое приложение, то у меня для тебя плохие новости. Чтобы написать что-то рабочее, тебе все равно придётся проделать эту работу. Просто делать ты это будешь не детерминировано, а по востребованию. В итоге ты опишешь процесс, но не уложишь его в своей голове, и качество твоего кода отреагирует. Багами, несвязностью и костылями.
Противники статической типизации говорят, что ранний отлов ошибок не так уж и важен.
Ало. Ваша доска с задачами набита багами, которые допустили разработчики. Чинить баги — большая часть всей работы в индустрии. Мы тратим миллиарды человекочасов, чтобы пофиксить до нелепости смешные ошибки. Вы пишите код без багов? или у вас только умные баги? Да хрен там плавал. Если бы компилятор не проверял за вас, что вы закрыли фигурную скобку, поверьте мне, у нас были бы сотни багов с незакрытой скобкой.
Когда думаешь о том, где баг потенциально может возникнуть, а где нет, появляется опасная иллюзия, что ты держишь ситуацию под контролем, и предусмотрел все кейсы. Я работаю семь лет, ещё ни разу не было такого, чтобы я предусмотрел все кейсы. Потому что это частный случай задачи коммивояжера — ты НИКОГДА не можешь предусмотреть все кейсы. Ты даже самые распространенные и вероятные рассмотреть не можешь. Когда, кто и в какой ситуации напишет код с критичным багом, в каком модуле и как он это сделает — ты, блин, понятия не имеешь. Все, что ты можешь сделать, это уменьшить шансы на появление бага. Вот и уменьшай, тебе за это платят бешеные деньги.
Противники статической типизации противопоставляют типы тестам.
Я не стану говорить, что они идиоты, я скажу, что они просто не подумали об этом хорошенько. Вот вам очевидная истина — тесты фиксируют, что существующий код работает по известным условиям. А типы гарантируют, что ещё не написанный код будет написан по известным условиям. Тесты нужны. Типы нужны. Ты все ещё уменьшаешь шансы, что все свалится. В мире, где у нас есть бюджет, чтобы пять часов обсуждать с командой, что не так в нашем эджайле, найдется время дописать аннотации и пару тестов.
Болваны из динамического мира говорят, что статическая типизация лишает код гибкости.
Я не понимаю, о какой гибкости они говорят. Даже в нищем C# система типов позволяет мне не иметь контроль над типами данных, чей тип не имеет для меня значения. Я всегда могу доказать языку, что вот, мол, слушай сюда, я не могу описать, что это за штука, но я точно знаю, что у нее есть вот такое поле, вот такого типа или вот такого типа. И я буду работать только с ним. Любой статически типизированный язык это позволяет. А гибкость и свобода писать код, который точно не сможет работать — такая гибкость мне не нужна.
JS-подростки говорят, что статическая типизация смещает акцент с задачи на описание типов.
А я говорю, что описание типов — и есть описание процесса, который ты автоматизируешь. В объектно-ориентированном программировании, в функциональном программировании, в любом другом программировании мы описываем вещи из реального мира, и наш код содержит те знания о них, без которых он не сможет работать. Ты все равно будешь проделывать эту работу.
Если система типов конкретного ЯПа не позволяет тебе описать свой домен правильно и защищено — это проблема конкретного языка, а не статической типизации в целом. Это нормально, и конкретно на этом языке ты местами используешь всякие object и dynamic, но везде где можешь получить гарантии — ты их получаешь.
Я писал код и с динамической типизацией, и со статической. Со строгой и нестрогой, со структурной и номинативной.