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

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

она самая

Видимо ответ "грядёт эра динамических языков", а не потому что поисковики с облаками?

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

0

Сообщение от pycture она самая

в дотнете все сериализуемые объекты динамических типов?
Тип может быть известен в ct, для него сгенерёна метаинформация которая будет использоваться в rt для сериализации.

Сообщение от pycture правильный ответ: потому как в статику также известную как реляционные бд пихать сложные объекты - хрен засунешь

т.е. со сложными объектами на плюсах, к примеру, не поработаешь?

0

Сообщение от KolodeznyDiver Где Вы такое определение нашли. Выражусь сдержано: это неправда.

Просто ваши убогие статикомпиляторы не умеют в компилирование кода в рантайме. =)

0

Сообщение от KolodeznyDiver в дотнете все сериализуемые объекты динамических типов?

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

т.е. со сложными объектами на плюсах, к примеру, не поработаешь?

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

0

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

Autodesk Inventor или 3ds Max как то со сложными объектами работают. Новая 3ds на С# написана, и не думаю что там сплошь динамики. Ранее это всё, вроде бы, на плюсах.

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

что за статические реляционки? Эти nosql-ли только со динамиками общаются, что ли? Да не верю.

0

Сообщение от KolodeznyDiver Autodesk Inventor или 3ds Max как то со сложными объектами работают.

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

что за статические реляционки

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

0

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

Что Вы подразумеваете под анимацией? На lua сценарии игр пишут, всякие поведения ботов. Не рендеринг же.

Сообщение от pycture обычные. с приколоченными колонками к таблице.

Я интересовался термином "статические реляционки".

Сообщение от pycture фиг что добавишь если заранее не прописано.

У разных баз и задачи разные. Но к теме про языки (а не базы) отношение не имеет, т.к. работать с ними можно и из статических языков.

0

Сообщение от KolodeznyDiver На lua сценарии игр пишут, всякие поведения ботов. Не рендеринг же.

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

Но к теме про языки (а не базы) отношение не имеет, т.к. работать с ними можно и из статических языков.

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

0

Сообщение от pycture что чуть сложнее пересылки байтиков - скрипты на динамике.

В играх? Чёт я сомневаюсь. Ну, допустим. Что "так принято" - это не аргумент .
Что, нельзя было бы использовать статический скрипт, например, Ваш любимый F# (.fsx)?
Ну, пусть он компилируется перед запуском, ну какой то другой скрипт.

Сообщение от pycture я не говорил что нельзя - я привел аналогию

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

0

Сообщение от KolodeznyDiver "ключ-значение"

0

Сообщение от korvin_ Речь шла про документо-ориентированных БД.

Ок. И противопоставление документо-ориентированных баз vs реляционные никакого отношения не имеет к данной теме.

0

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

и что это даст? статика от AV в рантайме еще никого не спасла, смысл в компилении?

здесь нет аналогии со статической и динамической типизацией

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

0

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

Это "быстро" за счёт чего получается?

Сообщение от pycture где применение статики неоправданно усложняет проектирование, удлиняет сроки реализации и приводит к набуханию проекта

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

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

0

Сообщение от KolodeznyDiver Это "быстро" за счёт чего получается?

за счет отказа от "неоправданно усложняет проектирование, удлиняет сроки реализации и приводит к набуханию проекта"

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

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

0

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

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

Сообщение от pycture сможете в статике сделать банальную вещь - описание железа компа

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


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

0

Сообщение от Voivoid толком не могут сформировать описание задачи

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

Что такое описание железа компа? Что оно из себя представляет,

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

какие к нему функциональные требования?

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

И почему хранить все в строке это читерство, из каких соображений?

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

Но повыступаю в роли телепата и предложу вариант с алгебраическими типами.

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

0

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

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

Сообщение от pycture датапомойка

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

Сообщение от pycture унылый вброс без примера не зачтется

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

struct Cpu { /* .... */ };
struct Ram{ /* ... */ };
struct Hdd { /* ... */ };
using HardwareUnit = boost::variant<Cpu, Ram, Hdd>;
std::map<std::string, HardwareUnit>;

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

Сообщение от pycture пока очевидно, что цопепе напрочь отбивает мыслительный процесс

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

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

Сообщение от pycture общения с заказчиками, которые всё, что могут родить это "я тут нажал и мне хорошо"

К счастью я избавлен от CRUD'ошлепства, написания парсеров магазинов и прочих задач аналогичного уровня

0

Voivoid, +1.

Сообщение от Voivoid Мол, сначала заведем какой-нибудь dictionary, а потом уже подумаем что дальше со всем этим делать.

Во, во. Зачем программе собирать данные о железе, класть в словарь, а потом, когда в коде нужно, скажем, число ядер, вытаскивать по ключу. Не нужно. В каком месте программы какая характеристика железа понадобится известно заранее. Даже если описание железа нужно вывести в виде отчёта, и то, потребуется разбить отчёт по разделам, Процессор, мать, память, графика ... И в каждом разделе жёстко заданные параметры.
И, если уж, требуется описание разнородных данных, то, всё равно, не всяких. Тут, разумеется алгебраический тип нужен, или, выражаясь по F#-ному, DU.Что бы мы не могли туда хэндл файла положить или даже не ту строку, т.к. потребуется строка с конструктором данных (в примере HwDescrStr и пр. в Haskell они так называются, не помню как в F#).

0

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

0

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

да.. датамайнинг для считальщиков факториалов слово незнакомое и страшное .

Все что я из твоей постановки задачи могу написать, так это

и? как теперь посчитать кол-во компов у которых объем дисков > 100 Гб и которые при этом ноуты?

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

я тожк на это сразу обратил внимание. вот один из таких

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

К счастью я избавлен от CRUD'ошлепства, написания парсеров магазинов и прочих задач аналогичного уровня

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

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

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

И, если уж, требуется описание разнородных данных, то, всё равно, не всяких.... DU.

уже оверхед в описаниях, при том что булов нет, флоатов нет, о вставке объекта произвольного типа (типа {os:string, version:VersionInfo}) даже речи нет. а если еще и заполнить коллекцию из 4 компов и попытаться с ней хоть немного поработать так вообще мало не покажется.

0