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

Я имею ввиду языки, в которых только или почти только используются динамически типизированные данных. Не будем сейчас рассматривать рефлексию, в языках .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

Сообщение от pycture откуда ж их взять то ? жестко заданные то? у ноута какая мать? а к тому компу 3 монитора подключены.

В дереве хранить.

Сообщение от pycture при том что булов нет, флоатов нет

А я и не собирался делать готовую программу. Просто пример для демонстрации описания типов. Если вообще стоит где либо так данные о железе хранить.

Сообщение от pycture о вставке объекта произвольного типа (типа {os:string, version:VersionInfo}) даже речи нет

Он легко разбирается в виде дерева. Но, да, не нужно его хранить деревом, а нужно статическим типом описанным в MSDN и имеющимся в .h файле SDK.

Сообщение от pycture а если еще и заполнить коллекцию из 4 компов

Да уж, очень сложная задача. ... для хранения в динамических типах, которые и есть деревья из примитивов, да ещё и с метаинформацией.
В статике всё просто.

Вы такое представление системной информации, видимо взяли из WMI, которое предназначено для использования в WSH, т.е. из динамических скриптов.

0

Сообщение от KolodeznyDiver А я и не собирался делать готовую программу.

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

Он легко разбирается в виде дерева. .... В статике всё просто.

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

Вы такое представление системной информации, видимо взяли из WMI, которое предназначено для использования в WSH, т.е. из динамических скриптов.

другого адекватного представления информации подобного типа (описать что угодно с заделом на будущее) нет. или динамика или эмуляция динамики в статике (целесообразность чего близка к 0).

0

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

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

Сообщение от pycture другого адекватного представления информации подобного типа

Мне кажется что Вы это ... скажем так несерьёзно. Вам уж не только я объясняли. Да и Вы, судя по активности на форуме, на статических языках пишите. Если Вы там, при любом случае, динамические типы используете не по делу, то ваши проблемы.

0

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

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

Мне кажется что Вы это ... скажем так несерьёзно. Вам уж не только я объясняли. Да и Вы, судя по активности на форуме, на статических языках пишите. Если Вы там, при любом случае, динамические типы используете не по делу, то ваши проблемы.

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

насчет объясняли... объяснять про сферических лошадей и я могу. вспомним это

Сообщение от KolodeznyDiver Под этими утверждениями есть какое то обоснование?

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

0

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

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

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

Это уже чистая демагогия. Вам объяснили как это решается в статике. Писать рабочую прогу для Вас, естественно, здесь никто не будет. И задачу Вы не поставили корректно.
Вывести через WMI описание железа компа (если Вы эту "киллер фичу" в кармане прятали) - это использовать встроенный в винду механизм. Впрочем, всё что надо, можно получить и без него.

Краткое резюме: я, в СП, написал более узкое утверждение - не нужны динамически типизированные языки. "Я имею ввиду языки, в которых только или почти только используются динамически типизированные данные." Но, возражения "динамистов" оказались, полностью не серьёзными, и, к тому же, перешли на оспаривание более широкого утверждения: нужны ли динамические типы вообще (а не динамические языки (см. выше)).
В результате я получил подтверждение своего первоначального тезиса и склоняюсь к тому что динамические типы не нужны вообще. Аргументы "динамщиков" про "набухания", невозможность статически описать сложные объекты, и что события от гуя можно обрабатывать только скриптами не стоят обсуждения.

p.s. Я был бы не прочь услышать аргументы за динамические типы. Но это действительно должно быть что то разумное.

0

Сообщение от KolodeznyDiver вывести через WMI описание железа компа (если Вы эту "киллер фичу" в кармане прятали)

придумывать совершенно другую (сведя решение к частному случаю) задачу и показывать как легко она решается в статике ни есть хорошо. какой еще wmi в линуксах/макосях?

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

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

0

Сообщение от pycture придумывать совершенно другую

Вы не описали цель корректно. Процитирую Вас :

Сообщение от pycture сможете в статике сделать банальную вещь - описание железа компа? без читерства типа всё в строках или object хранить, чисто статика. должно храниться перечень компонентов и их значения т.е. по факту Dictionary<string, ?> чтоб можно было перечислить ключи и получить значение по любому из них.

Я, и не только, уже спрашивали Вас "для чего это"? Конечная цель?

Сообщение от pycture статический яп от математиков и для математиков не смог вытеснить со своих ниш динамические R и MATLAB.

Там та же ситуация как и в вебе. Инерция мышления. Традиции. Математики и инженера до сих пор и на фортране с бейсиком пишут. Если выходить за рамки сравнения самих языков в область психологии, там, видимо находится ответ почему динамические языки существуют. Кто учил первым динамический язык, потом мне тут задаёт "риторический" вопрос "зачем такие списки нужны, если в них могут быть значения только одного типа?".

0

Сообщение от KolodeznyDiver Я был бы не прочь услышать аргументы за динамические типы.

Не нужно указывать явно типы, очевидно же. Конечно можно начать говорить про выводилки, но тут нужно понимать, что практически все статические языки, которые в ходу, не являются функциональными. Да и выводилки, конечно же, не всё выводят. Поэтому динамические императивные ЯП выглядят лаконичными, красивыми и привлекательными. И разрабатывать получается быстрее, даже не смотря на очевидные недостатки.

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

Сообщение от KolodeznyDiver невозможность статически описать сложные объекты

Конечно же в статике можно описывать объекты произвольной сложности. В статике нужно описать тип, построить объект, написать unit test. А в динамике только 2 пункта - построить объект, написать unit test. Описывать тип нет смысла, unit test проверит тип неявно.

0

Сообщение от nullxdth И разрабатывать получается быстрее

Только поначалу, пока кол-во кода не достигло критической массы.

Сообщение от nullxdth Описывать тип нет смысла

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

0

Сообщение от nullxdth Не нужно указывать явно типы ... Поэтому динамические ... ЯП выглядят лаконичными

Кодирование, в целом, занимает незначительное время в процессе проектирование ПО. Выигрыша времени из за указания типов нет, хотя бы потому что указание типа - это часть самодокументирования, т.е. выигрываем на комментариях. Естественно, если тип назван осмысленно - RowNum а не Int.

Сообщение от nullxdth динамические императивные ЯП выглядят лаконичными, красивыми и привлекательными.

Это, очевидно, субъективно. Наверняка влияет, кто с чего начинал и кто что знает.

Сообщение от nullxdth В статике нужно описать тип, построить объект, написать unit test. А в динамике только 2 пункта - построить объект, написать unit test. Описывать тип нет смысла, unit test проверит тип неявно.

Описать тип - это не лишняя работа. Самодокументированность (см. выше), возможность наложить ограничения на преобразования и операции с типом. IDE, учитывая типы, может нам предлагать более умные подсказки, в частности при построении объекта, т.е. п.2, упрощается. Юнит-тесты нужны но это не панацея. (Конечно, ничего не страхует от ошибок на 100%).
Сами юнит-тесты для статики упрощаются т.к. не нужно отдельно проверять корректность типов.

0

KolodeznyDiver
Мне кажется, что в словах nullxdth нечто интересное всё же есть.

В императивном программировании есть определённая тенденция писать код относительно неких "ящиков", с которыми связаны какие-то имена, а не относительно "объектов". Так гораздо удобнее мыслить деструктивные присваивания. Как-то в войнах проскакивала ссылка, где такой подход был сочно назван "place oriented programming". В рамках этого POP подхода "динамический тип" возникает естественно. Если у Вас есть имя s, которое связано с ящиком, то сложно дать этому имени какой-то тип... Сегодня в ящике "Hello Kitty!", а через три деструктивных присваивания -- число с плавающей точкой. Тогда любое выражение, в которое входит такое s, просто не может получить тип, потому что нужно расширить контекст до известного типа s, что можно сделать только уже запустив программу.

Когда код оказывается перегружен POP, то статическая типизация уже мешает. Она ничего существенного доказать про код не может, но крутить эти статические метки приходится постоянно.

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

IMHO

0

mporro, ну разве что "ящечно ориентированное программирование". И проектирование методом "хочу так, а потом подумаю". А, чё. Многие так и пишут.

0

Сообщение от nullxdth unit test проверит тип неявно.

Лол.
Если у тебя слабая динамическая типизация, то unit test вообще ничего не проверит.
Если же сильная, то все равно может быть фейл как минимум из-за duck typing'а

0

Сообщение от Voivoid Если у тебя слабая динамическая типизация, то unit test вообще ничего не проверит.

А кто тут говорит о слабых типизациях? Мы говорим о статической и динамической типизациях. Преимущественно подразумевая строгую типизацию и для статики и для динамики.
Если у тебя слабая типизация то и статика мало чем помогает. Посмотреть, например, хотя бы Си.

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

Сообщение от Voivoid Если же сильная, то все равно может быть фейл как минимум из-за duck typing'а

Да почему это? Ты тестируешь то поведение объекта которое тебе необходимо для корректной работы. Какая разница как был создан объект и что он из себя представляет? Главное он выполняет необходимые функции.

0

Сообщение от ct0r Для чтения явное указание типов всяко лучше.

нафига?

чем меньше необходимо знать и иметь ввиду, тем проще.
чем проще - тем лучше.

вот например, чистая статика:

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

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

но это уже ортогонально удобству чтения кода.

0

Сообщение от hoggy target.lock(); //<--- какая нафиг разница, * * * * //какой у него там точный тип * * * * // с точки зрения использования, это не принципиально * * * * // главное, что бы был метод lock

Если в языке любая переменная может лочится, то и так сойдёт. А если не всякая, то не обязательно указывать конкретный тип. Можно обобщённый, но поддерживающий lock . Или корневой класс иерархии, интерфейс. Способ от языка зависит. И это способствует чтению кода: по сигнатуре функции видно что ей надо.

0

Сообщение от KolodeznyDiver Если в языке любая переменная может лочится, то и так сойдёт. А если не всякая, то не обязательно указывать конкретный тип. Можно обобщённый, но поддерживающий lock . Или корневой класс иерархии, интерфейс. Способ от языка зависит. И это способствует чтению кода: по сигнатуре функции видно что ей надо.

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

0

Сообщение от hoggy вот например, чистая статика:

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

Сейчас используются тайпклассы для бедных:
А по-нормальному надо писать примерно так (когда везде будет поддержка концептов, не только в gcc):

0

Сообщение от hoggy мой цемес - можно вообще ничего не указывать.

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

0

Сообщение от ct0r Так на статике обычно не пишут, это говнокод.

эм.. а ничо что именно так почти все и пишут?
это самый заурядный плюсовый код.

Сообщение от ct0r По сигнатуре функции вообще не понятно, чем должен являться target

я ещё раз повторяю свой вопрос: на кой болт вам это нужно знать?

Сообщение от ct0r какой интерфейс поддерживать и так далее.

на кой болт это все нужно для понимания,
что делает функция?

Сообщение от ct0r Сейчас используются тайпклассы для бедных:

дык, это тоже самое.

ничем не отличается от:

Сообщение от ct0r А по-нормальному надо писать примерно так

нафигаааа?

мне не понятно, нафига вы все усложняете?

зачем делать сложно, когда можно тоже самое сделать просто?

зачем писать много, когда можно получить тоже самое,
но писать при этом мало?

зачем читать много,
когда для понимания достаточно малого количества информации?

объясните мне сакральный смысл, пожалуйста.

Добавлено через 51 секунду

Сообщение от KolodeznyDiver а потом, во время вывода на орбиту, попадёт на ветку где этой функции передаётся не лочимымый аргумент

Сообщение от hoggy вот например, чистая статика:

чукча не читатель?

или чукча не в курсе,
что такое "ошибки времени компиляции" ?

0