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

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

Сообщение от hoggy чукча не читатель?

По моему тут кто то другой чукча (со всем уважением к представителям народов севера). Ибо Вы же дальше написали

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

0

Сообщение от KolodeznyDiver Ибо Вы же дальше написали

ещё я там дальше писал:

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

Сообщение от KolodeznyDiver Тема, кста, по сути "динамические языки vs статические",

очевидно жеж, что это - тупой посыл.

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

0

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

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

0

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

А с чего ты взял, что эта функция ( void lock(auto& target); ) лочит примитив синхронизации, а не скажем отвечает за захват цели истребителем или например за запирание замка/дверей, или даже что-нибудь там связанное с ограничением прав?

0

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

меня несколько раздражает ваша узколобость.

во-первых, статика стремится предоставить дизайн динамики.
но ей до динамики ещё, как раком до китая.

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

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

и поэтому, вы мне не интересны.

0

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

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

0

Сообщение от KolodeznyDiver пытались таковые найти, точнее. Но таких нет в принципе.

по новой что ли?

поклали массив чаров
извлекаем как строку.

что бы это сработало нужно:

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

в статике о таких вещах даже не задумываются.
там все эти квесты за программиста выполняет компилятор.

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

задача не решается в статике в принципе.
даже при наличии статической рефлексии.

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

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



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

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

Сообщение от KolodeznyDiver Истина это то что приносит доход" (с) ?

да.

динамика - экономически выгодная.
это - единственное и достаточное условие её существования.

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


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

и пока это так - динамика будет оставаться востребованной.

0

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

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

Сообщение от hoggy динамика - экономически выгодная.

Дальше идут бездоказательные лозунги в духе

0

Сообщение от hoggy эм.. а ничо что именно так почти все и пишут?

Как они могут так писать, если auto в параметрах именованной функции запрещен стандартом?

Сообщение от hoggy на кой болт вам это нужно знать?

Чтобы корректно вызвать функцию. Как синтаксически, так и семантически. Или чтобы понять, могла ли моя последняя правка изменить ее поведение. Я же не просто так читаю сигнатуру.
Ты же не пишешь calculate_price(auto count, auto cost)? Вот фиг знает, count - целое число или вещественное?

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

Явный используемый интерфейс дает подсказку, как именно будет использоваться аргумент. И не дает доступа к той части его интерфейса, которая не нужна данной функции. Это же принцип разделения интерфейсов из SOLID со всеми его плюсами! Если мы меняем функцию в интерфейсе, то мы не должны как-то думать и заботиться о тех функциях, которые ее не используют. Иначе придется делать дополнительную работу - перелопачивать туеву хучу кода.

Сообщение от hoggy ничем не отличается от:

На уровне компилятора - не отличается. Но Lockable хоть чуть-чуть, но дает представление о том, что интерфейс параметра должен поддерживать что-то типа lock, try_lock и в этом духе. А то можно подумать, что сама функция lock может каким-то образом залочить любой объект, который туда передаешь.
А концепты дадут читабельный явный интерфейс со всеми его плюсами + вменяемые сообщения об ошибках.

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

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

0

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

Ой не смеши. Давно ты свои калькуляторы начал на орбиту выводить? А надёжность и отказоустойчивость в таких системах решается комплексом мер, СТ среди которых далеко не самая важная. Ну и да: в случае ошибки в какой-то функции, в CL, например, эту функцию можно будет исправить на лету, без остановки всей программы и возвращения аппарата с орбиты. А что можно сделать с программой на Хаскелле? Или любой другой статике?

0

korvin_, ну C, С++, OCaml, Ada частенько летают. Про CL не слышал ничего.

0

Сообщение от ct0r ну C, С++, OCaml, Ada частенько летают. Про CL не слышал ничего.

https://en.wikipedia.org/wiki/... mote_Agent

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

Сообщение от ct0r C

А, это тот «статически типизированный» язык, в котором всё легко кастится в (*void) и обратно без каких-либо проверок компилятором?

0

Сообщение от korvin_ надёжность и отказоустойчивость в таких системах решается комплексом мер

Именно. Насколько там важна статическая типизация можно спорить бесконечно. По своему опыту (и, да, мои проги в космос не летают, но баг убытки тоже немалые может принести) знаю что СТ необходима в комплексе мер по отказоустойчивости. Но это личное мнение.
А вот объективно: стандарты безопасности в милитари, авионике и подобном требуют если не Аду то OCaml и точно не динамику.

Сообщение от korvin_ в случае ошибки в какой-то функции, в CL, например, эту функцию можно будет исправить на лету

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

0

Сообщение от ct0r Как они могут так писать, если auto в параметрах именованной функции запрещен стандартом?

как то так:
http://rextester.com/VAP11281

Сообщение от ct0r Чтобы корректно вызвать функцию. Как синтаксически, так и семантически.

вам не нужно ничего вызывать на момент чтения кода.

за синтаксисом уже проследил компилятор.
за семантикой - автор кода.

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

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

разумеется могла.
раз это скомпилировалось.

и не может, если не скомпилировалось.

при чем тут тип объекта?

Сообщение от ct0r Ты же не пишешь calculate_price(auto count, auto cost)?

пишу.

Сообщение от ct0r Вот фиг знает, count - целое число или вещественное?

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

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

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

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


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

Сообщение от ct0r И не дает доступа к той части его интерфейса, которая не нужна данной функции.

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

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

Сообщение от ct0r Если мы меняем функцию в интерфейсе

значит мы меняем сам интерфейс.
значит у нас куча проблем и с клиентами (легаси),
и с реализацией.

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

как то не понятно, а что, бывает и такое,
что приходится?

Сообщение от ct0r Но Lockable хоть чуть-чуть, но дает представление о том, что интерфейс параметра должен поддерживать что-то типа lock, try_lock и в этом духе.

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

нахрена при этом знать его тип?

допустим, obj - это объект класса "стиральной машинки",
или "таблица", "база данных", "запись",
да мало ли.

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

я задам ещё раз вопрос:
зачем писать много, если тоже самое можно получить,
написав мало?

Сообщение от ct0r А концепты дадут читабельный

вы прикалываетесь?

такое же нечитабельное говно,
как и вся шаблоно магия.


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

что бы вместо сообщения от компилятора "объект не умеет lock",
получить тоже самое, только слегка другими словами?

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

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

0

korvin_, но, как я понимаю, все по некоторым причинам закончилось фигово, и уже лет 15 на CL особо нет ничего? http://www.flownet.com/ron/RAX2.pdf Или я ошибаюсь?

Сообщение от korvin_ А, это тот «статически типизированный» язык, в котором всё легко кастится в (*void) и обратно без каких-либо проверок компилятором?

Угу. Правда я лично знаком только с теми, кто для низкоорбитальных спутников использует C++.

Сообщение от hoggy как то так:

Ну это ж gcc. У него и концепты есть. Но по стандарту С++14 auto допустим только в параметрах лямбд. Можешь проверить на любом другом компиляторе. Так что сейчас этот код абсолютно непереносим.
Все остальное контекстно связанное ты растаскал на цитаты, а я не могу отвечать за каждую из них вне контекста.
Отмечу только, что пример с локом - это очень частный пример, на котором не надо зацикливаться. Представь, что у нас длинная цепочка шаблонных функций. И находить косяк в передаче параметра 1-ой функции по ошибке в 12-ой - занятие утомительное.

Сообщение от hoggy такое же нечитабельное говно, как и вся шаблоно магия.

Это характерное свойство С++, чего уж тут.

Добавлено через 4 минуты
hoggy, короче, если быть точным, то этот твой auto в параметрах именованной функции - часть Concept TS. http://en.cppreference.com/w/c... onstraints

0

Сообщение от ct0r Так что сейчас этот код абсолютно непереносим.

так мы ж не о переносимости говорим.

Сообщение от ct0r Представь, что у нас длинная цепочка шаблонных функций. И находить косяк в передаче параметра 1-ой функции по ошибке в 12-ой - занятие утомительное.

обычно достаточно просто прочитать диагностику компилятора.

0

Сообщение от KolodeznyDiver Горячая замена софта возможна и для статики.

Либо с кучей ограничений, либо совершенно не безопасно.

Сообщение от ct0r но, как я понимаю, все по некоторым причинам закончилось фигово

По организационным. В NASA вдруг осознали, что занимаются совершенно не тем, для чего они создавались и существуют. Во всяком случае, так говорит чел в видео. А с технической точки зрения, по его словам, проект оказался полностью успешен.

0

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

А это не задача. Задача это, скажем, посчитать кратчайший путь или например отрендерить 3d модель, провести моделирование какого-то явления. То, что ты собираешься микроскопом забивать гвозди это не проблема микроспока

0

Сообщение от Voivoid То, что ты собираешься микроскопом забивать гвозди это не проблема микроспока

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

0

Сообщение от korvin_ Либо с кучей ограничений, либо совершенно не безопасно.

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

0