Динамически типизированные языки : один вред, никакой пользы

Я имею ввиду языки, в которых только или почти только используются динамически типизированные данных. Не будем сейчас рассматривать рефлексию, в языках .NET или java – там используются динамические типы, но используется сама рефлексия относительно редко.

Где ещё, якобы нужна динамическая типизация?

Для доступа к БД? Не нужна, если сама БД не написана на динамическом языке и/или не специально спроектирована для взаимодействия с динамическим языком. Если посмотреть API конкретных СУДБ (например, oracle, postgreSQL, Firebird/Interbase, SQLite) или ODBC API, то выяснится, что динамическая типизация не нужна.

Для JSON ? Нет, не нужна. Библиотеки для работы с JSON реализованы, наверное, для всех распространённых, статически типизированных языков.

Метапрограммирование? Смотря какое. Если под ним подразумевать выполнение строки кода введённого пользователем, то может оказаться и нужна. Только это для скриптов. При чём для скриптов без предкомпиляции (хотя бы в байт код). Сейчас 21 век, и код, даже на скрипте, должен вначале хотя бы парситься с проверкой типов весь, что бы не выгребать баги лопатой после жалоб пользователей (тулзы типа JSHint, это эрзацы. Декларации типов должна быть встроены в язык и несоответствия обнаруживаться компилятором.). А если под метапрограммированием понимать перекладывание на компилятор генерацию рутинных, повторяющихся кусков кода, то такое метапрограммирование (как и программирование вообще), предпочтительно типобезопасное и в динамической типизации не нуждается.

Сторонники динамических языков часто возражают примерно так «мне нужно, что бы переменная xyz принимала то значение строки, то значение вот с эдакой структурой». Заметим, на практике, если уж мы будем работать с содержимым xyz, то кол-во вариантов конечно, и ограничено логикой программы (да, для выполнения, например, копирования xyz в другую область памяти, нам ничего кроме ссылки и размера не нужно, но не для работы с конкретным её содержимым). А раз так, то xyz может быть алгебраического типа. В pascal можно заменить на запись с вариантами, в С на union и пр.

Распространённость динамически типизированных языков я связываю со временем, когда web-сервера были практически только у провайдеров, а они разрешали абонентам использовать на своих страницах почти только perl и php. В те времена ни о какой предкомпиляции и JIT слыхом не слыхивали. Как и о песочницах. Интерпретаторы этих скриптов делали на коленке и каждый помаленьку. По этому они, впрочем как и js, по дизайну напоминают письмо из простоквашино. Потом скрипты «возмужали» и «заматерели», обзавелись кое где JIT-ом, но примитивность динамической типизации осталась.

Не даром сейчас полным ходом идёт разработка и внедрение языков со статической типизацией компилируемых в js (TypeScript, Elm), а php держится за счёт инерции мышления (как фортран или кобол), не более.

Да, есть ещё вполне динамический, и более свежий Ruby. Ну, дык, его автор сам до того прогал на perlе, стало быть привык к динамической типизации, да и рассчитывал на любителей перловки.

Собственно, я что хочу сказать. В конкретном, динамически типизированном скрипте могут быть очень интересные и полезные фенечки за что его могут любить прогеры с ограниченным знанием языков. Только фенечки фенечками, а динамическая типизация бяка. Почему бяка? Ну, легко нагуглить, и навикипедить. Использовать же в компилируемом языке динамическую типизацию – вообще маразм. Исключение – языки выполняемые на виртуальной Erlang машине со встроенной динамической типизацией. Автор (или кто то из разрабов) утверждал что иначе механизм динамической замены кода не получался. Со скрипом, поверим на слово. Тем более, что там стараются контролировать типы на уровне библиотеки.

0

Сообщение от KolodeznyDiver Да, на макросах в скобках, создают управляющие конструкции языка - циклы, например, но необходимость таких макросов скорее и указывает на низкоуровневость языка.

Необходимости в таких макросах нет, ведь всевозможные циклы давно написаны и входят в стандарт. А в книгах они часто приведены как пример простых макросов, чтобы немного понять идею. Всё дело в том, что циклами макросы не ограничиваются. Неужели так сложно предположить, что если возможно средствами языка программировать управляющие конструкции, то может быть можно и делать нечто большее? И потом чуть погуглить и, например, нагуглить PAIP.

Добавлено через 1 минуту

Сообщение от KolodeznyDiver но оно там, опять же, не типизированное

Ну, как выяснилось, и в Haskell они не очень-то типизированные.

Добавлено через 1 минуту

Сообщение от KolodeznyDiver На самом деле (только никому не говорите) я полистывал P.Seibel. Practical Common Lisp - надо же знать своего врага в лицо.

Как обычно. Читаешь книгу - видишь фигу. Типичный Haskell fanboy.

Добавлено через 3 минуты

Сообщение от KolodeznyDiver Не даром сейчас полным ходом идёт разработка и внедрение языков со статической типизацией компилируемых в js (TypeScript, Elm)

Не льсти себе. Если и TypeScript где и используется, то Elm не использует никто. А из трансляторов в js наиболее широко используется CoffeeScript, который динамика.

0

Сообщение от KolodeznyDiver Использовать же в компилируемом языке динамическую типизацию – вообще маразм.

почему же?

0

Сообщение от hoggy почему же?

(точнее, ещё больший маразм).
Потому что в скриптах теряется основное преимущество статической типизации - обнаружение несоответствия типов во время компиляции. Ну, и выигрыш в скорости в скриптах не так важен обычно.

0

Сообщение от KolodeznyDiver Потому что в скриптах теряется основное преимущество статической типизации - обнаружение несоответствия типов во время компиляции.

ну и что?
вы осознаете причину существования динамической типизации?
потому что это удобно.

я повторю свой вопрос:
почему вы считаете использование динамической типизации
в статически компилируемом языке маразмом?

в чем профит статической типизации? это - удобно.
компилятор помогает находить множество ошибок.
они легко правятся, процесс бежит быстро,
и волосы у программиста мягкие и шелковистые.

но если в каком то моменте удобнее задействовать динамическую типизацию,
то скорее уж маразм - это отказ от удобства в пользу менее удобных подходов.
разве это не очевидно?

0

Сообщение от hoggy вы осознаете причину существования динамической типизации?

Анахронизм. (В подавляющем большинстве случаев. Возможно всегда).

Сообщение от hoggy но если в каком то моменте удобнее задействовать динамическую типизацию,

Я имел ввиду

Сообщение от KolodeznyDiver языки, в которых только или почти только используются динамически типизированные данных

. Вот, если такой язык компилируемый, то это маразм.
Вы поняли как "почему это нельзя в статическом языке иногда использовать dynamic ?".
Так остро я вопрос и не ставлю, бывают случаи. Хотя мне кажется что динамическая типизация не нужна никогда. Но, если, иногда, в особых случая, то пусть себе.

0

Сообщение от KolodeznyDiver Вот, если такой язык компилируемый, то это маразм.

например, питон - скрипт, но его можно скомпилировать.
это может быть востребовано для оптимизации.
почему же сразу маразм?

Сообщение от KolodeznyDiver мне кажется что динамическая типизация не нужна никогда

скажем так: там, где она нужна,
технически всегда существует возможность
реализовать через статику.

вопрос лишь в удобствах.

статическое решение не всегда бывает удобным.
в динамике конечно нет такой железобетонной безопасности,
но зато есть простота использования.

0

Сообщение от hoggy почему же сразу маразм?

См. выше.

Сообщение от hoggy статическое решение не всегда бывает удобным

Пример? Может я чего то упускаю? (только словами, please. Пайтон я не знаю).

0

Сообщение от KolodeznyDiver См. выше.

посмотрел.
я повторю свой вопрос:
что такого маразматичного в возможности скомпилировать скрипт,
тем самым ускорив его работу?

Сообщение от KolodeznyDiver Пример?

например, есть кнопка,
по нажатию на которую должна запуститься функция пользователя.

однако разработчик гуя понятия не имеет,
какие у пользователя могут быть функции, типы, и тп.
в общем не известно, что именно нужно будет запускать,
и с какими аргументами.

в динамике все просто - что укажет, то и запустится.
в статике пришлось бы решить целый ряд инженерных задач.


другой пример: есть библиотека для построение 3д сцены.
сцена представляет собой некое дерево, узлы которого - какие то графические объекты.
этим объектам пользователи хотят сопоставить какие то свои данные.

однако библиотека понятия не имеет, что там за данные могут быть у пользователей.

третий пример:

нужна функция, способная принимать ссылку на объект любого типа.
точный тип будет известен лишь времени выполнения.
(например - та самая юзерская дата для 3д сцены)

это не проблема. в статике можно построить универсальный тип данных,
способный хранить внутри объекты любого типа.

проблема начинается при извлечении:
нужно убедиться, что тип приёмника данных соответствует посылке.

что бы не получилось так:
отправили строку, а забираем, как циферку.

проблема в том, что отправить мы можем строку,
а забирать как массив буковок.
то есть нет точного соответствия типов.

в статике, когда заранее известны тип посылки и приемника,
такой проблемы не существует.
компилятор может сгенерировать код приведения типов.

но если тип посылки известен лишь времени выполнения,
то это становится не возможным в принципе.

итого: на статическом языке проблема общего решения не имеет.

была бы полноценная динамика,
тогда всегда можно было бы спросить:
"посылка, а ты умеешь массив буковок?"

0

Сообщение от hoggy в динамике конечно нет такой железобетонной безопасности, но зато есть простота использования.

Бгг, толпы быдла долбятся головами об стену не видя двери - для них выпиливают люк

Сообщение от hoggy в статике пришлось бы решить целый ряд инженерных задач.

Сообщение от hoggy однако библиотека понятия не имеет, что там за данные могут быть у пользователей.

Сообщение от hoggy но если тип посылки известен лишь времени выполнения, то это становится не возможным в принципе.

Ну, где-то в начале 80-х, да, были с этим некотроые проблемы, но сейча уже, напомню, 2015.

0

Сообщение от hoggy что такого маразматичного в возможности скомпилировать скрипт, тем самым ускорив его работу?

Если скрипт можно скомпилировать, то лучше бы типы в нём определялись явно. Преимущества статической компиляции см. выше. Исторически пайтон был сделан вначале скриптом, так что, "так получилось". Если бы в браузерах изначально был бы встроен типизированный скрипт, а не js, то много бы нервов сэкономили бы, времени и денег.

Сообщение от hoggy например, есть кнопка

Зачем функции-обработчику клика передавать какие то пользовательские данные из библиотеки реализующей сам гуй?

Сообщение от hoggy другой пример: есть библиотека для построение 3д сцены. сцена представляет собой некое дерево, узлы которого - какие то графические объекты. этим объектам пользователи хотят сопоставить какие то свои данные.

Что значит сопоставить объектам данные? Подозреваю что это сводится к примеру выше. В современных языках, в обоих случаях, пользовательские данные можно передать через замыкание.

Сообщение от hoggy (например - та самая юзерская дата для 3д сцены)

Тот же случай что выше (для 3д сцены).

Сообщение от hoggy в статике можно построить универсальный тип данных, способный хранить внутри объекты любого типа

Если с этими данными хранить и код типа, то получится динамический тип. Вернулись к началу - зачем это надо?

Сообщение от hoggy если тип посылки известен лишь времени выполнения

Тип посылки не может быть каким угодно. Он может быть одним из конечного числа вариантов, которые программа "знает" как обрабатывать. Лучшее решение тут - применить Алгебраический тип данных имеющийся в языках, происходящих от ML (OCaml,Haskell,F#) или записи с дискриминантами в языке Ада. (В сущности, это одно и тоже). Возможно, что то аналогичное, есть в других языках. Записи с вариантами в паскале до АТД не дотягивают.

Добавлено через 1 минуту

В остальном, всё верно.

0

Сообщение от Voivoid толпы быдла долбятся головами об стену не видя двери - для них выпиливают люк

не очевидно, к чему это было сказано.

Сообщение от Voivoid где-то в начале 80-х, да, были с этим некотроые проблемы, но сейча уже, напомню, 2015.

2016.

я хочу использовать полиморфизм.
у меня есть ссылка на объект базового класса.

напомните мне пожалуйста,
как обеспечить типо-безопасность извлечения данных,
хотя бы времени выполнения,
с возможностью приведения типов?

Сообщение от KolodeznyDiver Если скрипт можно скомпилировать, то лучше бы типы в нём определялись явно.

изначальная посылка была, что это уже - скрипт, и уже динамический.
мне просто захотелось скомпилировать его в натив, с целью ускорения его работы.

я ещё раз повторю свой вопрос:
что в этом такого "маразматического" ?

Сообщение от KolodeznyDiver Преимущества статической компиляции см. выше.

к чему это было сказано?

очевидно жеж,
что преимущества статической типизации - монопенисуальный фактор там,
где выбор пал на динамику.

Сообщение от KolodeznyDiver Если бы в браузерах изначально был бы встроен типизированный скрипт, а не js, то много бы нервов сэкономили бы, времени и денег.

я не люблю подобные рассуждения по двум причинам:

1.
история не знает сослагательного наклонения.

2.
бизнес все расставляет по своим местам.
это - объективное мерило эффективности решения задач.
и это мерило говорит мне:
эту нишу захапали динамические языки.

Сообщение от KolodeznyDiver Зачем функции-обработчику клика передавать какие то пользовательские данные из библиотеки реализующей сам гуй?

"из библиотеки" - звучит как то криво.


юзер может назначить кнопке (и любому другому виджету)
какие то пользовательские данные.
при нажатии на кнопку,
эти данные должны быть переданы на обработку в функцию,
которую он укажет.

это - типичная ситуация для гуя.

собственно все реакции на клики только в том и заключаются,
что при клике нужно позвать какую нибудь функцию.

Сообщение от KolodeznyDiver В современных языках, в обоих случаях, пользовательские данные можно передать через замыкание.

если под "замыканием" вы подразумеваете лямбду,
которая захватила некоторый контекст,
то вы ошибаетесь.

проблема не в том, как захватить данные любых типов.
а в том, как их потом извлечь обратно.

Сообщение от KolodeznyDiver Если с этими данными хранить и код типа, то получится динамический тип.

ага. но это если утрировать.
потому что динамический язык - это целая технология.
и если она не поддерживается языком,
то проэмулировать её на статическом языке будет не просто.
выше я писал вам, что без поддержки компилятора,
невозможно выполнить извлечение с возможности приведения типов.

Сообщение от KolodeznyDiver Вернулись к началу - зачем это надо?

что бы не приходилось вручную велосипедить механику,
которая умеет динамические типы.

Сообщение от KolodeznyDiver Тип посылки не может быть каким угодно. Он может быть одним из конечного числа вариантов, которые программа "знает" как обрабатывать.

нет, не знает.

попробую привести ещё один пример:

есть два объекта. "сериализатор" и "дата".
они ничего друг про друга не знают.

точный тип сериализатора становится известным лишь времени компиляции,
но может быть различным в зависимости от параметров с которым он создается.

дата - всего лишь интерфейс, у которого может быть 100500 наследников.
фактический тип данных становится известным лишь времени выполнения.

нужно сериализовать дату.

если бы дата не была полиморфным интерфейсом,
то можно было бы сделать что-то вроде:

в статике сериализатор смог бы "просканировать" тип объекта,
и слить его в поток.

проблема в том, что в той точке, в которой нужно выполнить сериализацию,
есть только указатель на базовый интерфейс даты.
а вот точный тип конкретной даты не известен,
и может быть любым из 100500 возможных наследников.

в этой ситуации есть только два пути:
1.
передать наследнику даты знание о фактическом типе сериализатора.

2.
передать сериализатору знание о фактическом типе конкретного наследника.

ни то, ни другое не решается в статике.
решения не существует в принципе.

0

Сообщение от hoggy напомните мне пожалуйста, как обеспечить типо-безопасность извлечения данных, хотя бы времени выполнения, с возможностью приведения типов?

Если ты про возможность через интерфейс базового класса получить интерфейс наследника, то you are doing it wrong. Все равно что сначала забить гвоздь в стену, а потом спрашивать как при помощи молотка ( и только его ) достать гвозь обратно

Добавлено через 10 минут

Сообщение от hoggy не очевидно, к чему это было сказано.

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

0

Сообщение от hoggy изначальная посылка была, что это уже - скрипт, и уже динамический. мне просто захотелось скомпилировать его в натив, с целью ускорения его работы. я ещё раз повторю свой вопрос: что в этом такого "маразматического" ?

При такой постановке вопроса: "уже скрипт" ничего маразматического. Улучшаем что есть как можем.

Сообщение от hoggy юзер может назначить кнопке (и любому другому виджету) какие то пользовательские данные.

Возможно в пайтоне или ещё где то так делается. Но в большинстве распространённых GUI-ев так не делается.
Или обработчик клика - это член класса, данные он сам возьмёт из своего экземпляра класса, или данные передаются через замыкание или каррирование.

Сообщение от hoggy если под "замыканием" вы подразумеваете лямбду, которая захватила некоторый контекст, то вы ошибаетесь. проблема не в том, как захватить данные любых типов. а в том, как их потом извлечь обратно.

??? Мне неизвестна такая проблема.

Сообщение от hoggy ага. но это если утрировать. потому что динамический язык - это целая технология.

Никакого утрирования. В динамическом языке данные идут вместе с их описанием во внутреннем представлении. Никакой таинственной технологии, одни тормоза.

Сообщение от hoggy точный тип сериализатора становится известным лишь времени компиляции ... фактический тип данных становится известным лишь времени выполнения ... проблема в том, что в той точке, в которой нужно выполнить сериализацию, есть только указатель на базовый интерфейс даты. а вот точный тип конкретной даты не известен, и может быть любым из 100500 возможных наследников

Это подход динамической типизации. При статической вышеперечисленные ситуации не возникают. Сериализация в нормальных языках описывается через метапрограммирование. Никаких проблем с ней при статической типизации не наблюдается.

0

Динамика гуд, если нужно забабахать скрипт или маленький прототип.
Для всего остального статика предпочтительнее.
Это даже питоняши усекли:
http://www.infoq.com/news/2014... n-proposal
http://stackoverflow.com/quest... python-3-5

Добавлено через 1 минуту
В хаскеле кстати есть довольно интересная весчь по типам и их структуре http://chrisdone.com/posts/data-typeable

Добавлено через 24 минуты
hoggy, кстати статика в плюсах далека от идеала, если ты с ней сравниваешь. Да, она уже не настолько слаба как в сях, но далеко не сильна. И типы для абсолютно всего автоматом не выводятся нормально, приходится везде указывать конкретно или через auto. Посмотри как реализована система типов хаскела - это пример того, как должно быть.

Добавлено через 10 минут
Короче, если сравнивать плюсы с хаскелем, то система типов в
плюсах - слабая явная
хаскеле - сильная неявная

0

Просто некоторым реальным прогерам не даёт покоя мысль что есть мало распространённые динамически типизированные языки, круче чем кастрированная статически типизированная попса, которой они деньги зарабатывают. На мой взгляд ситуация такая. Динамические больше подходят для индивидуальной разработки, а статические для командной. Бизнес выбирает статику, потому что считает что проект важнее кодера, которому можно дать пинка под зад, если тот будет слишком много качать права, и взять на его место другого, который быстрее въедет в тему, так как статический язык легче читается, лучше документируется, и выглядит структурированнее.

0

Lambdik, ну то есть питон и руби для отдельных индивидуумов, а окамл для команды. Да, такое сейчас в бизнесе повсюду наблюдается, все только на окамле и фигачат, это ты верно подметил

0

Сообщение от Lambdik мало распространённые динамически типизированные языки

Ок, ну вот ты сказал, что в статически-типизированные языкы " легче читается, лучше документируется, и выглядит структурированнее." Ок. А чем же круты "мало распространённые динамически типизированные языки" ?

0

Сообщение от Voivoid Если ты про возможность через интерфейс базового класса получить интерфейс наследника, то you are doing it wrong.

я пишу не про возможность,
а про невозможность поиметь общее решение в статике.

все очень просто:

нет возможности гарантировать безопасность извлечения.

максимум что тут можно сделать - это
заранее предусмотреть возможность приведения типов
для ограниченного количества случаев.
универсальный тип данных в статике построить невозможно.

как следствие, в статике не возможно построить
полноценный динамический делегат, например.

Сообщение от Voivoid К тому, что куча людей не осиливают как пользоваться системами типов. Как следствие, вместо того, чтобы использовать статическую типизацию для повышения надежности и понятности кода они начинают ( с разной степенью успешности ) с ней бороться при помощи всяческих костылей. Для таких людей решение одно - языки с динамической системой типов

неосиляторы меня не интересуют.
мой изначальный посыл был:
причина существования статической типизации,
равно, как и динамической - тупо в удобстве использования.

есть задачи, с которыми статика справляется плохо (не удобно),
либо не справляется вообще.

есть задачи, для которых динамика просто не нужна.

Сообщение от KolodeznyDiver большинстве распространённых GUI-ев так не делается. Или обработчик клика - это член класса, данные он сам возьмёт из своего экземпляра класса, или данные передаются через замыкание или каррирование.

вы правы... почти.
это "почти" все портит.

лямбда - функтор, который генерируется компилятором на лету.
в плюсы завезли сравнительно недавно, например.
в то время, как ваше "большинство гуёв" - гораздо старше.
так что в большинстве гуёв нужно сначала приготовить этот самый функтор вручную:
наследуемся от базового ивента.
наследник тащит на своём борту юзер-дату.
кнопка выстреливает базовым ивентом,
а юзерский код выполняет приведение к наследнику,
после чего делается извлечение.

и так каждый раз с каждой очередной юзер-датой.
запаривает, если честно писать километры кода для реализации простых вещей.

это именно то, что я имел ввиду, когда писал вам:
"технически, в статике можно, но это будет не удобно".

отдельные приседания связанны с такими вещами,
как "проперти виджета", "лэяуты", и тп.

с динамикой проблем нет - прямо на лету добавляем свойства виджету,
как угодно меняем поведения,
а все изменения сразу видны и из редактора, и целевому приложению.

в статике это такой аццкий геммор.

проще расширять базовые наборы виджетов в исходных кодах,
и пересобирать всю библиотеку, что бы "применить изменения".

Сообщение от KolodeznyDiver В динамическом языке данные идут вместе с их описанием во внутреннем представлении. Никакой таинственной технологии, одни тормоза.

вот только попытка решить тот круг задач,
который они решают - это велосипедирование технологии в статическом языке,
и как следствие - те же самые "тормоза".

вы мне сейчас напомнили новобранца, который:
"о боже! виртуальные функции - это же оверхед! тормоза"

отказ от виртуальных функций у него привел к созданию собственного велосипеда:
тот же самый опосредованный вызов функции через промежуточный указатель.

Сообщение от KolodeznyDiver Сериализация в нормальных языках описывается через метапрограммирование. Никаких проблем с ней при статической типизации не наблюдается.

проблему, которую я описал вам выше невозможно решить в статике,
даже при наличии статической рефлексии.

Сообщение от ct0r кстати статика в плюсах далека от идеала, если ты с ней сравниваешь. Да, она уже не настолько слаба как в сях, но далеко не сильна. И типы для абсолютно всего автоматом не выводятся нормально, приходится везде указывать конкретно или через auto.

я не о статическом выводе типов. с этим то как раз проблем нет.
я о том, что если фактический тип наследника
становится известным лишь времени выполнения,
то в статике в принципе невозможно стукнуть лбами двух наследников.

можно попробовать пойти например таким путем:

но это - не более, чем описание кучки частных случаев извлечения.

реализовать единый общий для всех типов алгоритм извлечения невозможно.

с поправкой на метапрограммирование - не возможно в принципе:
потому что для этого потребуется реализовать шаблоно-виртуальную функцию
что не возможно в принципе.

именно для имитации шаблоно-виртуальной функции и нужны "универсальные типы".

но здесь мы натыкаемся уже на их ограничения:
либо полный запрет на приведение типов.
либо работать будет лишь кучка заранее описанных частных случаев приведения.



динамические языки существуют для того,
что бы простые вещи делались просто.

без необходимости применять тяжелую артиллерию в виде метапрограмминга,
который максимум на что способен - удовлетворить кучку частных случаев,
которые придется описывать вручную.
а потому - суть костыль.

0

Сообщение от hoggy много букф

Чет даже не знаю что и сказать, потому что из всей этой стены текста я особо ничего не понял Вроде все слова знакомые, но в разумные и логичные предложения они не складываются.

0

Сообщение от Voivoid Чет даже не знаю что и сказать, потому что из всей этой стены текста я особо ничего не понял Вроде все слова знакомые, но в разумные и логичные предложения они не складываются.

если вкратце: динамика нужна,
что бы простые вещи делались просто,
и не приходилось долбаться с ограничениями статики.

0