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

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

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

С чего ты взял, что они только на динамических языках писали?

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

Мне лень искать, если честно. Но вот чел пишет про юнит-тесты и типизацию на примерах реальных проектов: https://drive.google.com/file/... view?pli=1
Можешь прочитать только начало и конец.

Ну и вообще вот есть такая статейка по качеству кода http://macbeth.cs.ucdavis.edu/lang_study.pdf

Сообщение от nullxdth Ну это же пипец какой-то, как там это хозяйство записывается. Реализация не многим лучше, чем идея записывать аннотации типов в docstring-ах

Дело вкуса. Кому-то лучше в некоторых местах так, чем скобки везде

0

Сообщение от ct0r Дело вкуса. Кому-то лучше в некоторых местах так, чем скобки везде

Ну да, точно. Скобки вида {-@ ... @-} и прочий сраный ascii-арт, куда приятнее, чем обычные нормальные скобки. Я, право, не понимаю, почему не такие скобки, например: {-[[!!!111 ... 111!!!]]-}: так было бы гораздо круче. Дело вкуса однако.

0

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

В геоинформационных системах. В частности, для работы с этой штукой: ENVI. Там применяется хитрый язык IDL (Interactive Development Language) - динамически типизированный язык сценариев. Живет уже давно, жив до сих пор и помирать не собирается.
При обработке спутниковых данных эти самые данные поставляются вендором в самых разных форматах (TIFF, GeoTIFF, HDF, Shapefile, и прочая) с кучей метаданных, с различной внутренней структурой каталогов (как в HDF с его B-деревьями), с различными типами данных внутри (int, float, double, long, string, etc). Ситуация, когда нужно использовать инфу с различных ИСЗ (а стандарта по сути нет, есть EOS со своей терминологией (NASA), но не везде применяют и не всегда) - совмещать, сравнивать, дополнять данные из разных источников - вещь весьма распространенная.

0

Сообщение от cmath В геоинформационных системах. В частности, для работы с этой штукой: ENVI. Там применяется хитрый язык IDL (Interactive Development Language) - динамически типизированный язык сценариев. Живет уже давно

Мало ли что где живёт. Динозавры тоже жили. Я не говорю, что там надо срочно всё переделать, но преимущества там от динамики нет.

Сообщение от cmath При обработке спутниковых данных эти самые данные поставляются вендором в самых разных форматах (TIFF, GeoTIFF, HDF, Shapefile, и прочая) с кучей метаданных, с различной внутренней структурой каталогов (как в HDF с его B-деревьями), с различными типами данных внутри (int, float, double, long, string, etc).

Повторюсь из этой темы "В статике это деревья и списки из ADT, где варианты в ADT - это заранее известный, тот самый набор примитивных типов.". Парсинг данных разных форматов на статике, минимум не хуже. Наверняка есть либы для работы со всем этим, как они есть для JSON и XML для (почти?) всех языков.

0

Сообщение от KolodeznyDiver есть либы

Для hdf5 есть hdfDotNet для C#.NET, есть еще библиотека для C++, но они работают медленее, и поддерживать код под них тяжелее, все преимущество от типобезопасности убьется об сложность разработки. Для меня главный смысл динамической типизации - это возможность найти общее решение задачи, вместо того, чтобы писать некоторое (пусть и не очень большое) множество частных.
***

Сообщение от KolodeznyDiver В статике это деревья и списки из ADT

Нужен класс-полиморф, в котором будет абстрактная функция, которая будет возвращать либо int, либо float, либо double, либо bool в зависимости от того, какой конкретно тип данных содержит потомок, можно, конечно, возвращать указатель void *ptr на возвращаемое значение, но вот загвоздка - все данные используются для проведения математических операций и нужно свести к минимуму все операции сравнения/приведения типов, поскольку данные будут обрабатываться в некотором цикле, и данных очень много, не тысяча элементов, и даже не миллион, а, самое маленькое - миллиард, но в основном это будет довольно большое число минимум с двенадцатью знаками в его записи. Да, еще очень возможно, эти классы будут использоваться в составе матриц и более тяжелый вещей с количество измерений от 3 шт. Предложите свое решение на abstract data type.
Это, кст, вполне типичная задача, с которой приходится иметь дело. Без проверки типов - не безопасно - да, но зато работает быстро и выглядит проще. А данные нужны сейчас, а не через год, месяц и даже неделю, т.к. от них может, в том числе, зависеть чья-то жизнь (при стихийных бедствиях).

Сообщение от KolodeznyDiver но преимущества там от динамики нет

Слишком категоричное заявление, тем более что с указанной системой вы ни разу не работали. Специфика области вынуждает создавать такие вещи, как IDL, иначе бы его просто не было, или это была бы столь обожаемая вами статика. ЭТО НЕ PHP и создавалось научными работниками для научных же работников. Все было просчитано и разрабатывалось из потребностей практики, IDL не используется для ширпотреба и приложения на нем обычный пользователь в своей жизни никогда не увидит, только созданные на их основе продукты.

0

Сообщение от cmath Без проверки типов - не безопасно - да, но зато работает быстро

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

0

Voivoid, я не сторонник динамической типизации. Я сторонник подхода - каждой задаче свой инструмент. Я не ищу идеальное решение, я ищу эффективное. А на счет проверки типов - в C++ в runtime проверять типы приходится с помощью довольно таки медленных высокоуровневых конструкций (когда счет на микросекунды), в то время как в динамике при хорошей реализации все происходит на низком уровне.
***
Так кто-нибудь предложит решение задачи из поста #165 в статике? Я жду.

0

Сообщение от cmath в то время как в динамике при хорошей реализации все происходит на низком уровне.

Бггг, вот о чем я и говорю, магия динамики... Как ты себе это представляешь-то?

Сообщение от cmath Так кто-нибудь предложит решение задачи из поста #165 в статике? Я жду.

Да эта задача тут уже несчетное число раз всплывала, в первом приближении достаточно алгебраиеских типов, если например речь о C++, то boost::variant

0

Сообщение от cmath Нужен класс-полиморф, в котором будет абстрактная функция, которая будет возвращать либо int, либо float, либо double, либо bool в зависимости от того, какой конкретно тип данных содержит потомок, можно, конечно, возвращать указатель void *ptr

Ни в коем случае. Я же написал про ADT, он же Алгебраический тип данных (а не abstract data type), он же discriminated union. Можно его возвращать. В языках, в которых этого нет, можно вначале запросить тип, потом значение конкретного типа. Всё равно, обрабатывать придётся в разных ветках. int явно не так надо обрабатывать как string. А, на самом деле, типов "по смыслу" обычно больше чем примитивных типов, т.е. int координата и int кол-во и ещё всякое, и каждый обрабатывается по своему.

Сообщение от cmath и нужно свести к минимуму все операции сравнения/приведения типов

ну, по скорости, грамотно спроектированная статика всегда быстрее.

Сообщение от cmath с указанной системой вы ни разу не работали

Не важно. Всё сводится к деревьям, спискам, ADT. Динамические типы данных так и хранятся. Плюс лишние проверки в run-time.

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

Этот язык, видимо, предметно ориентированный (DSL), и такие языки нужны, но это параллельная классификация языков. Существование же динамически типизированных языков (и появление новых), в том числе среди DSL, объясняется, как полагаю, инерцией мышления (выучившему динамический язык трудно понять как может быть иначе). Ну ещё написание интерпретатора скрипта немного упрощается, если там, всё равно, будут хранится динамические данные. Можно бы было сделать их проверку в compile-time, но делать это разработчики первых скриптов не стали. Не сколько от лени, сколько от тормознутости тогдашнего железа. Так и пошло. А теперь даже в динамически типизированные языки (в JavaScript) вынужденно компилируют из статических (TypeScript, elm, PureScript, ...).

0

Сообщение от KolodeznyDiver А теперь даже в динамически типизированные языки (в JavaScript) вынужденно компилируют из статических (TypeScript, elm, PureScript, ...).

Или из динамических, что чаще всего. Один только CoffeeScript по частоте использования перекрывает все перечисленные.

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

Сообщение от KolodeznyDiver Ну ещё написание интерпретатора скрипта немного упрощается

Хех. Если бы "немного". Статика сама по себе ставит жирный крест на интерактивной разработке, ввиду невозможности реализации адекватного REPL-а. То есть, выбери статику - скажи нет интерактивной разработке в образе.

0

Сообщение от nullxdth Один только CoffeeScript по частоте использования перекрывает все перечисленные.

Я уже говорил, что частота использования, сама по себе для меня не аргумент. В данном случае причина очевидна - на кофе переползало много жаваскриптеров. Им так привычнее. (Я сам немного был жскриптером, вот там и прочувствовал недостатки динамики.)

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

REPL не для отладки, а для создания программ - это маразм. Но вопрос "++-- интерактивной разработки ПО из терминала" отдельная тема. А для отладки возможностей REPL-ов Haskell, F# достаточно. Тем более, что отлаживать чаще стоит другими способами (тоже отдельная тема, интересная, кста).

0

Сообщение от KolodeznyDiver REPL не для отладки, а для создания программ - это маразм.

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

0

Сообщение от nullxdth интерактивная разработка становится невероятно удобным и эффективным занятием.

Признаюсь, что слабо представляю как это, и не представляю как при этом можно получить что то кроме г-кода. Как это происходит в общих чертах, без примеров на скобках? Шаг проектирования при этом тоже в REPL-е или его вообще нет? Почему это нужно делать в REPL-е, а не в графической среде? Вы уверены что динамика для этого принципиальна? Некоторые ide для статических компилируемых языков, в ходе отладки позволяют смотреть/изменять значения и даже переписать часть кода с частичной перекомпиляцией и продолжением отладки без перезапуска приложения. Не являются ли возможности конкретного средства интерактивной разработки для скобок конкретного динамического языка никак от статика-динамика независящие? Ну и есть ли какие то статьи-книги доказывающие эффективность такого подхода не на примере скобок, ибо, если только для них, то это докажет обратное.

0

Сообщение от nullxdth Статика сама по себе ставит жирный крест на интерактивной разработке, ввиду невозможности реализации адекватного REPL-а

Не вижу никаких принципиальных проблем. Скажем тот же repl haskell'а (ghci) вполне себе работает. Кстати даже для C++ есть калечный repl в visual studio

0

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

бред.

Сообщение от cmath Так кто-нибудь предложит решение задачи из поста #165 в статике? Я жду.

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

любое решение в статике - это то,
что под капотом у вашей динамики.

решений множество.
и самое простое из них:
в дебаге делаем проверки типо-безопасномти.
в релизе - не делаем.

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

0

Сообщение от hoggy у вашей динамики под капотом тормозной интерпретатор

Это заблуждение. Динамика далеко не всегда означает интерпретатор. Почти никогда не означает, в современном мире.

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

Сообщение от Voivoid Скажем тот же repl haskell'а (ghci) вполне себе работает. Кстати даже для C++ есть калечный repl в visual studio

REPL REPL-у рознь. Lisp REPL полноценен и разработка в образе является основной конкретно в Common Lisp.

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

Сообщение от KolodeznyDiver Признаюсь, что слабо представляю как это, и не представляю как при этом можно получить что то кроме г-кода.

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

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

Сообщение от KolodeznyDiver Как это происходит в общих чертах, без примеров на скобках?

Запускаешь среду, загружает весь runtime языка с необходимыми библиотеками. И прям в среде начинаешь писать всякие выражения, функции и прям из среды компилируешь/выполняешь выражения. Пишешь, например, какой-нибудь web service и прям в реальном времени меняшь поведение всяческих entrypoint-ов и отлаживаешься на месте.

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

Сообщение от KolodeznyDiver Шаг проектирования при этом тоже в REPL-е или его вообще нет?

Проектирование происходит по ходу дела, ну максимум на шаг два вперёд.

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

Сообщение от KolodeznyDiver Почему это нужно делать в REPL-е, а не в графической среде?

REPL не всегда означает какой-то там консольный интерфейс. Всё можно делать из любимой IDE.

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

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

Да, позволяют. Типа С++ в Visual Studio. Но там куча ограничений. А тот же Lisp позволяет менять поведение всего. В том числе самого себя. Сам язык так спроектирован, что бы это было возможным и, что важно, удобным.

0

Сообщение от nullxdth Разработка снизу вверх

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

Сообщение от nullxdth Проектирование происходит по ходу дела, ну максимум на шаг два вперёд.

Сообщение от nullxdth REPL не всегда означает какой-то там консольный интерфейс. Всё можно делать из любимой IDE.

REPL - это REPL, т.е. терминал (консоль), хоть куда вставленный. B VS, для F# можно выделить фрагмент, Alt-Enter и он выполнится в другом окне, в REPL. Но создавать исходник в REPL маразм, представляю какой потом код получится.

0

Сообщение от KolodeznyDiver Только снизу вверх для хоть сколь ни будь сложных проектов приведёт к многократному переписыванию и стимулирует г-код.

Я даже не хочу пытаться тут объяснить почему эта твоя фраза абсолютна наивна и невежественна.
Чуть наброшу бисера:
https://en.wikipedia.org/wiki/... -up_design
http://paulgraham.com/progbot.html
https://en.m.wikipedia.org/wiki/Worse_is_better

Вообще разговор о подходах к проектированию/разработке глубоко дискуссионный. Ты не готов к нему

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

Сообщение от KolodeznyDiver REPL - это REPL, т.е. терминал (консоль),

read-eval-print loop. Понимать под этим "терминал (консоль)" конечно можно, но слишком уж узко и тупоголово.

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

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

Да брось! Ты и представляешь?

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

Сообщение от nullxdth https://en.wikipedia.org/wiki/Top-do...ttom-up_design

Более точная ссылка: https://en.wikipedia.org/wiki/... evelopment

0