Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, varenikAA, Вы писали:
AA>>TDD избавляет от таких ошибок.
P>Так что, типы не нужны? TDD идет им на смену?
Возможно, но типы они такие — описывают теоретическую модель. А данные гораздо сложнее моделей.
Пример json-а вполне реальный — из api rocket.chat.
Т.е. имея два четко определенных типов, на все равно придется городить кастомную десериализацию.
Причем это сработает, только если у нас будет возможность их четко отсортировать по наличию каких-то сигнальных полей.
Ну или вообще хадкорно, 1 — это один тип, 2 — это другой.
Опять приходит к необходимости рекурсирвного обхода токенов вручную.
Я другого пути не вижу.
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, varenikAA, Вы писали:
AA>>(def js (json/read-str "[{ \"msg\" : \"Привет\"}, { \"room\" : \"Курилка\"}]":key-fn keyword))
BFE>Я не знаю, нужны ли вам типы, но вот разделения кода и данных тут точно нет. А ну как кто-то в динамике добавит 42794967295 элементов массива? Завилтся ваше приложение набок, а в случае с линакс
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, varenikAA, Вы писали:
AA>>Так почему мы все еще используем типы?
AA>>Есть json такой args : [{msg : "Привет"}, {roome : "Курилка"}] AA>>(filter (fn [e] (:room e)) js)
DM>Хотя бы поэтому. Без них некоторые и трех строк корректно написать не могут. И такой простой баг может прожить довольно долго, пока будет найден.
Здравствуйте, ltc, Вы писали:
ltc>Здравствуйте, varenikAA, Вы писали:
AA>>Так почему мы все еще используем типы?
ltc>Моё мнение — типов нужно даже гораздо больше, чем есть сейчас. ltc>А ты делаешь какие-то глобальные выводы на примере решения очень частной задачки.
Малое или большое лишь размеры. Суть прежняя. Если в малом такие проблемы, то что мы получим в большой системе?
Еще большую сложность, которая не сущностная, а чисто техническая.
Здравствуйте, Mamut, Вы писали:
AA>>Так почему мы все еще используем типы?
M>Типы ты используешь всегда. Разница в том, когда эти типы проверяются — на этапе компиляции (статика) или в рантайме (динамика). Плюс целый спектр между этими двумя. Плюс soundness vs. unsoundness системы типов. Плюс строгая vs. слабая типизация. Плюс уровни сахара в реализации языка. Плюс сложность самого языка.
M>В итоге строгий статически типизированный язык с, например, автоматическим выводом типов, sum и intersection типами и плюшками типа pattern-matching может вполне себе зарулить по удобству динамически-типизированный язык. В теории.
M>На практике всё — говно.
Максимальный опыт у меня с C#. Строгую типизацию встретил в F#(проекты для дущи и мелкая автоматизация каких-то задач)
чуть позже Nemerle. C# в принципе умеет неявно приводить, а динамик вообще решает проблему десериализации.
Nemerle тоже умеет в ExpandObject, правда там приходится все приводить явно. Не уверен, что это хорошо. Возможно это просто иллюзия контроля над ситуацией.
Nemerle не говно, если выбирать статику. Но блин уже хочется dotnet core.
Clojure если динамику.
Здравствуйте, Kolesiki, Вы писали:
K>Здравствуйте, varenikAA, Вы писали:
AA>>Есть json такой args : [{msg : "Привет"}, {roome : "Курилка"}] AA>>При этом в clojure (ДиНаМиКа!!!!) все делается 3-мя строчками: AA>>Так почему мы все еще используем типы?
K>Потому что мы не пишем 3-строчные ОнКлики на говностраничках?
K>Типы — они придуманы не ради гемороя, а для надёжности. Вот как раз для таких случаев: какой-то клоун передаёт тебе в сервис ахинею, а сервис просто отбрасывает "левые" объекты и работает только с регламентированными.
В том то и дело, что не отбросил, и не упал, а передал дальше по цепочке вызовов не-инициализированную структуру с null-полями. Это кстати большой вопрос к F#. А может нет, Есть заточенные под F# сериализаторы. Скорее всего там с контролем получше. Но тогда зачем вводить CLIMutable? Чтобы обойти защиту F# типов? Приплыли.
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, varenikAA, Вы писали:
AA>>Так почему мы все еще используем типы? S> А в F# нет динамиков?
Есть какое-то FSharp.Interop.Dynamic
Скорее всего просто пара функций для удобства работы с ExpandoObject
Ну, тогда зачем типы? Если таже кложа намного проще в работе с динамикой?
Да, даже в C# как-то проще, из-за меньшей строгости.
Здравствуйте, vsb, Вы писали:
P>>Классическое (JS): P>>
P>>'2'+3="23"
P>>'2'-3=-1
P>>
P>>Может, конечно, мои взгляды на жизнь устарели, и оно так и надо...
vsb>Так типы тут никуда не девались. В Java тоже можно написать "2" + 3 = "23". Это просто идиотская философия JavaScript, пытаться исполнять код до последнего, они там напридумывали всяких имплиситных преобразований, потому и получается так. Возьми Lua, там всё гораздо лучше.
Самое интересное, что в Javascript реализациях это меняется — хотя по-человечески сделать всё равно не хотят.
Вот тут (оригинала что-то не видно), или тут:
Здравствуйте, Буравчик, Вы писали:
0>>Потому что они дают возможность устранения определенного класса ошибок в программе ценой некоторого неудобства 0>>Иногда этот trade-off выгоден. Б>Не иногда, а часто выгоден.
Не часто, а всегда. Попробуй показать пример, когда не выгоден.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, varenikAA, Вы писали: P>>Классическое (JS): P>>
P>>'2'+3="23"
P>>'2'-3=-1
P>>
P>>Может, конечно, мои взгляды на жизнь устарели, и оно так и надо... AA>TDD избавляет от таких ошибок.
То есть ты предпочитаешь написать гору тестового кода вместо строгой типизации?
Молодец.
Здравствуйте, alexanderfedin, Вы писали:
A>Здравствуйте, varenikAA, Вы писали: P>>>Классическое (JS): P>>>
P>>>'2'+3="23"
P>>>'2'-3=-1
P>>>
P>>>Может, конечно, мои взгляды на жизнь устарели, и оно так и надо... AA>>TDD избавляет от таких ошибок. A>То есть ты предпочитаешь написать гору тестового кода вместо строгой типизации? A>Молодец.
Разве тесты не являются своего рода спецификацией?
Когда пишется тест, то определяется "что", но не "как".
Типы это тоже самое тестирование только со стороны языка/компилятора.
Тут скорее вопрос в другом являются ли типы строго-типизированного языка
100% отражением структур данных которые подаются на вход?
Если писать интеграцию с системой вроде рокет-чата, то вариантов упасть из-за несоответствия типов будет больше
чем если изначально не надеятся на то, что структуры данных извне всегда будут строго соответствовать типам доменной модели.
и даже если мы в преобразовании на входе оборачиваем все в Option Some или None, то чем это лучше безтиповой проверки
let getUsername data =
match data.username with
| Some val -> val
| None -> "noname"
(or (:username data) "noname")
;или просто проверка на нуль:
(nil? (:username data))
Здравствуйте, varenikAA, Вы писали:
AA>Типы это тоже самое тестирование только со стороны языка/компилятора.
То же самое. Только для этого не надо тесты писать.
AA>Тут скорее вопрос в другом являются ли типы строго-типизированного языка AA>100% отражением структур данных которые подаются на вход?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, varenikAA, Вы писали:
AA>>Типы это тоже самое тестирование только со стороны языка/компилятора.
НС>То же самое. Только для этого не надо тесты писать.
Разница не только в подходах. TDD вроде в парах кодят — первым пишет код тестировщик,
вторым разраб. На типах наоборот. Но главное, типы определяют, чего мы ждем от внешнего мира.
В динамике мы лишь можем предположить что вот это нам сейчас придет, если нет выполнение можно продолжить без ошибок.
AA>>Тут скорее вопрос в другом являются ли типы строго-типизированного языка AA>>100% отражением структур данных которые подаются на вход?
НС>А они должны?
В том то и беда, что ООП очень сильно внушило мысль, что данные тождественно равны объектам.
Из-за этого появляются ненужные абстракции в приложении, которые вносят существенную сложность,
вопреки задачи — упростить решение.
Здравствуйте, varenikAA, Вы писали:
AA>Разница не только в подходах.
Разница тольков том, надо ли писать тесты на то что контролирует система типов, или нет.
AA>Но главное, типы определяют, чего мы ждем от внешнего мира.
Нет.
НС>>А они должны? AA>В том то и беда, что ООП очень сильно внушило мысль, что данные тождественно равны объектам.
Здравствуйте, varenikAA, Вы писали:
AA> Но главное, типы определяют, чего мы ждем от внешнего мира. AA>В динамике мы лишь можем предположить что вот это нам сейчас придет, если нет выполнение можно продолжить без ошибок.
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, varenikAA, Вы писали:
AA>> Но главное, типы определяют, чего мы ждем от внешнего мира. AA>>В динамике мы лишь можем предположить что вот это нам сейчас придет, если нет выполнение можно продолжить без ошибок.
DM>Вот на эту тему недавно подробная заметка была, много бурления вызвала: DM>https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/
Не силен в английском, но хаскел читается намного тяжелее жаваскрипта, да и кода в разы больше.
Можно из этого сделать вывод, что хаскел круче жээса?
Здравствуйте, varenikAA, Вы писали:
AA>Есть какое-то FSharp.Interop.Dynamic AA>Скорее всего просто пара функций для удобства работы с ExpandoObject AA>Ну, тогда зачем типы? Если таже кложа намного проще в работе с динамикой? AA>Да, даже в C# как-то проще, из-за меньшей строгости.
