Ок, у нас есть схема. И все равно, в чем профит-то по сравнению с динамически-типизированным языком? Вот вы потратили кучу сил на написание библиотеки, работающей с json, а дальше она не даёт вам никаких преимуществ статической типизации. И динамическая реализация, и статическая примерно одинаково выбросят ошибку, но на динамическую реализацию потрачено на два порядка меньше сил (на разработку библиотеки).
Да, схема обычно известна (или некоторый кусок схемы, который при обновлении стороннего API может дополняться). Представить его в виде статического типа можно, но для этого нужно быть очень неленивым.
Вы предлагаете (небезопасно) приводить типы по месту. Но где же тут хоть одно преимущество статической типизации реализуется?
На входе и на выходе обработки будут нужные типы (невелика задача и для динамической типизации), а в середине — как получится. Подвержено ошибкам в рантайме оно будет ничуть не меньше, чем код на динамическом языке. Единственная надежда — что компилятор заставит написать обработку исключения про неправильное приведение типов или заставит проверить тип перед приведением. Но компилятор так придирчив как минимум не во всех статически типизированных языках.
Не очень понимаю, как проверка типов помогла бы в том примере (не работал с монгой и не знаю, что за тип у этих операторов и чем такой словарик будет отличаться от обычного {string=>string})?
Попробуйте описать результат парсинга произвольного json в статически типизированном языке. Работая с такими объектами вы теряете все плюсы статически типизированного языка, ибо только в рантайме станет ясно, что вы ошиблись с типами входящих данных. В compile time вы не знаете, какого типа json[«name»], и даже не знаете, корректное ли это выражение.
Чем динамический язык тут лучше? Вам не придется заводить обертки над значениями примитивных типов и руками распаковать их значения (а вам придется, если только у вас в языке нет union-type). Библиотека для работы с json в статически типизированном языке по сути будет реализовывать свою «динамическую типизацию».
Кроме того, в динамическом языке вы спокойно можете писать литералы, соответствующие нужному вам объекту. Я не знаю, есть ли хоть один статически типизированный язык, который вам позволит такое.
А задача работы с пришедшим извне json — типичнейшая.
У вас в голове дикая путаница.
а) «Мой друг хотел делать наоборот — сразу писать код и не описывать никакие типы. Он не был готов определять проблему в виде семейства типов».
«Это не значит, что динамически типизированные языки не нужны (на самом деле я и правда думаю, что не нужны). Это значит, что при их использовании, тебе нужно отказаться от ООП, как главенствующей парадигмы».
«Канонические реализации большинства ООП паттернов пестрят кейвордом Interface, который совершенно бессмысленнен в динамически типизированном языке.»
Вы очень узко смотрите на ООП. ООП — это не какая-то одна цельная парадигма, а очень широкий спектр различных вариантов ввести в язык объекты.
Ну вот, например, вы сетуете на то, что в динамически типизированных языках интерфейсы не декларируются явным образом (хотя используются постоянно). А вы в курсе, что статически типизированный ООП-язык C++ не имеет интерфейсов вообще, и предлагает совершенно другие способы решения проблем?
Динамические языки вполне себе описывают типы — возьмите Smalltalk и всех его последователей. Мне как человеку из ruby-мира с его тщательно продуманной системой типов просто смешно читать про то, что динамическая типизация — это отказ от продумывания пользовательских типов.
JS — не лучший и далеко не самый типичный пример ООП-языка с динамической типизацией.
б) «Паттерны — штука кросс-языковая». Эээ? Нет, паттерн — это всего-лишь типичное решение типичной проблемы. И в разных языках наборы задач и решений разные. Множество паттернов упростилось (вплоть до полного вырождения) с появлением в языках лямбда-функций, это же не повод поливать лямбды грязью и требовать возвращения всех тех сложностей, которые приходилось без них решать заведением специальных классов.
в) «Главный плюс статической типизации — гарантия. Если ты используешь ее в одном модуле, а в другом нет, ты просто потратил время и силы на описание и разработку типов, а никаких гарантий не получил.»
Часть модулей вашего кода получила гарантии согласованности. Если код настолько немодульный, что вы не получили никаких гарантий, то это просто плохой код. Статическая типизация его не исправит (скорее уж наоборот, законсервирует лишние взаимосвязи).
в') Ага, а потом ваши гарантии разбиваются о какую-нибудь ковариантность коллекций, хе-хе.
(прошу прощения за некропостинг, но вдруг кто-то ответит)
Меня смущает пример про естественное преобразование и функтор точки. Кажется, что существование стрелки a -> b в C не является необходимым для существования естественного преобразования Point_a ->Point_b. Ведь единственная стрелка, с которой естественное преобразование должно быть совместимо — это единичная стрелка в категории 1 (которая отображается на единичную стрелку в категории С).
Да ладно? Если у вас адресная строка совмещена с поисковой, а у поисковой есть auto-suggest, то браузер чуть ли не автоматом слил инфу в ваш поисковик ещё до того как вы нажали enter.
Хм. Я думал, что у них черный список стоит почему-то перед белым, но не думал, что там просто может быть многослойная структура фильтрации. Возможно, стоило просить о внесении в белый список на глобальной вики (кстати, английская вики и глобальная — синонимы?)
Впрочем, пока в России википедию не заблокировали, лень разбираться; проще VPN отключать.
Александра Элбакян пишет: «В статистике также отбрасываются обращения с облачных сервисов Амазона и Гугла, расположенных в США». И утверждает, что в США прокси как раз менее доступны.
Так я про то и говорю. Я наткнулся на это ровно в тот момент, когда не смог править википедию через свой приватный VPN.
Что меня удивило — это что они не могут добавить в белый список конкретный IP, если он входит в заблокированный диапазон. Но это уже оффтоп.
Следить за авторским правом — задача не РКН, а издателя. В России, насколько я знаю, наказания за нелегальное скачивание объектов авторского права нет, но есть ответственность за распространение. Судя по тому, что торренты живут, даже эта ответственность де-факто (широко) не применяется. Но вы же в России, тут невозможно заранее знать, остаёшься ли ты в рамках закона, поскольку рамки постоянно двигаются. :) Use it on your own risk.
Тем не менее, мы видим, что китайцы качают больше всех. Мне кажется, это немного противоречит вашей гипотезе.
Мы же говорим не про всех китайцев, а про учёных. Работать в современной науке, не зная английского фактически невозможно.
Ну так это примерно эквивалентные вещи. У меня своя VPS на DO, работает в том числе как прокси, но не открытый, а закрытый — т.е. не попадает под это правило. Проблема в том, что все всю подсеть википедия отнесла к потенциально открытым прокси.
Вы предлагаете (небезопасно) приводить типы по месту. Но где же тут хоть одно преимущество статической типизации реализуется?
На входе и на выходе обработки будут нужные типы (невелика задача и для динамической типизации), а в середине — как получится. Подвержено ошибкам в рантайме оно будет ничуть не меньше, чем код на динамическом языке. Единственная надежда — что компилятор заставит написать обработку исключения про неправильное приведение типов или заставит проверить тип перед приведением. Но компилятор так придирчив как минимум не во всех статически типизированных языках.
Не очень понимаю, как проверка типов помогла бы в том примере (не работал с монгой и не знаю, что за тип у этих операторов и чем такой словарик будет отличаться от обычного {string=>string})?
Чем динамический язык тут лучше? Вам не придется заводить обертки над значениями примитивных типов и руками распаковать их значения (а вам придется, если только у вас в языке нет union-type). Библиотека для работы с json в статически типизированном языке по сути будет реализовывать свою «динамическую типизацию».
Кроме того, в динамическом языке вы спокойно можете писать литералы, соответствующие нужному вам объекту. Я не знаю, есть ли хоть один статически типизированный язык, который вам позволит такое.
А задача работы с пришедшим извне json — типичнейшая.
а) «Мой друг хотел делать наоборот — сразу писать код и не описывать никакие типы. Он не был готов определять проблему в виде семейства типов».
«Это не значит, что динамически типизированные языки не нужны (на самом деле я и правда думаю, что не нужны). Это значит, что при их использовании, тебе нужно отказаться от ООП, как главенствующей парадигмы».
«Канонические реализации большинства ООП паттернов пестрят кейвордом Interface, который совершенно бессмысленнен в динамически типизированном языке.»
Вы очень узко смотрите на ООП. ООП — это не какая-то одна цельная парадигма, а очень широкий спектр различных вариантов ввести в язык объекты.
Ну вот, например, вы сетуете на то, что в динамически типизированных языках интерфейсы не декларируются явным образом (хотя используются постоянно). А вы в курсе, что статически типизированный ООП-язык C++ не имеет интерфейсов вообще, и предлагает совершенно другие способы решения проблем?
Динамические языки вполне себе описывают типы — возьмите Smalltalk и всех его последователей. Мне как человеку из ruby-мира с его тщательно продуманной системой типов просто смешно читать про то, что динамическая типизация — это отказ от продумывания пользовательских типов.
JS — не лучший и далеко не самый типичный пример ООП-языка с динамической типизацией.
б) «Паттерны — штука кросс-языковая». Эээ? Нет, паттерн — это всего-лишь типичное решение типичной проблемы. И в разных языках наборы задач и решений разные. Множество паттернов упростилось (вплоть до полного вырождения) с появлением в языках лямбда-функций, это же не повод поливать лямбды грязью и требовать возвращения всех тех сложностей, которые приходилось без них решать заведением специальных классов.
в) «Главный плюс статической типизации — гарантия. Если ты используешь ее в одном модуле, а в другом нет, ты просто потратил время и силы на описание и разработку типов, а никаких гарантий не получил.»
Часть модулей вашего кода получила гарантии согласованности. Если код настолько немодульный, что вы не получили никаких гарантий, то это просто плохой код. Статическая типизация его не исправит (скорее уж наоборот, законсервирует лишние взаимосвязи).
в') Ага, а потом ваши гарантии разбиваются о какую-нибудь ковариантность коллекций, хе-хе.
Меня смущает пример про естественное преобразование и функтор точки. Кажется, что существование стрелки a -> b в C не является необходимым для существования естественного преобразования Point_a ->Point_b. Ведь единственная стрелка, с которой естественное преобразование должно быть совместимо — это единичная стрелка в категории 1 (которая отображается на единичную стрелку в категории С).
Впрочем, пока в России википедию не заблокировали, лень разбираться; проще VPN отключать.
Что меня удивило — это что они не могут добавить в белый список конкретный IP, если он входит в заблокированный диапазон. Но это уже оффтоп.
Мы же говорим не про всех китайцев, а про учёных. Работать в современной науке, не зная английского фактически невозможно.